Migrating Off Attaché: A Step-by-Step Process Guide

Three decisions before you start

Before a single record is touched, three decisions need to be locked down. Getting them wrong mid-project is expensive.

Which platform are you moving to? This shapes everything: the data model you are transforming to, the APIs available, what native features can replace Attaché functionality, and what needs custom building. Xero, MYOB Advanced, NetSuite, and Dynamics 365 Business Central all have meaningfully different data models. You cannot start building ETL pipelines without knowing the destination.

How much historical data are you taking across? Moving three years of history is a very different project from moving fifteen. Most businesses do not need all historical transactions in the live system. Opening balances can be set at a cut-off date, with older data archived in a read-only Attaché instance or exported to a reporting tool. Decide the cut-off before mapping data.

What is your cutover date? The cutover date drives the timeline backward. Most businesses target end-of-month, end-of-quarter, or end-of-financial-year. End of financial year simplifies opening balances significantly and is usually the preference where the timeline permits. If you are targeting 30 June, work backward: that means parallel running should start no later than 1 May, which means test migration and validation should be done by late April.

Getting data out of Attaché

Attaché does not use a standard SQL database in older versions. Getting data out requires one of three approaches.

Attaché's built-in export tools. Attaché can export many entities to CSV or Excel. This works for simple data extracts but is not sufficient for a full migration. The exports lack referential integrity, some fields are not available through the UI, and the process is manual and error-prone for large data sets.

ODBC connections. Attaché supports ODBC access to its underlying database. This is the most reliable approach for structured extraction. You can query tables directly, join related data, and extract large volumes programmatically. ODBC requires a connection string and credentials from the Attaché server. Your Attaché administrator or an ODBC-capable developer can set this up.

Direct database access. For complex or high-volume extractions, direct read access to the Attaché database files provides the most control. This requires understanding the Attaché database format, which varies by version. It is the approach used for migrations where ODBC performance is insufficient or where non-standard data needs recovering.

The entities you need to extract, roughly in order of priority:

• Chart of accounts: Account codes, names, account types, and opening balances at your cut-off date
• Customer records: Names, ABNs, addresses, contact details, payment terms, and account balances
• Supplier records: Same fields as customers, plus bank account details for EFT payments
• Open AP and AR: All unpaid invoices and bills at the cut-off date. These are what the new system needs to operate from day one
• Transaction history: The volume of history you decided to migrate in decision two above
• Payroll employee records: Employee details, pay rates, leave balances, YTD figures. Payroll migration often runs as a separate workstream
• Inventory items: If applicable. Item codes, descriptions, prices, quantities on hand
• Job and project records: If your business uses Attaché's job costing module
• Custom fields: Any custom fields added to Attaché over the years. These need mapping to equivalent fields in the target platform or to custom fields you create there

Data quality problems you will find

Almost every Attaché database that has been running for more than five years has accumulated data quality issues. These need fixing before loading into the new system, not after. Cleaning data in the target platform is significantly harder than cleaning it in a staging environment.

Duplicate records. Customer and supplier records that were entered twice, often because staff could not find the existing record. Common patterns: same business with different ABN formats, same individual with name variations, or records created for a one-off transaction that were never linked to the main record. A deduplication pass before migration is essential.

Inconsistent data formats. Phone numbers in seven different formats. Postcodes as text and as numbers. Addresses with the suburb in the street field. Date fields that have been used for notes. These inconsistencies need normalising before load, because the target platform's validation is usually stricter than Attaché's.

Orphaned transactions. Transactions linked to accounts or contacts that no longer exist in Attaché. These cause foreign key violations on load. They need either linking to active records or archiving before migration.

Characters that break modern systems. Special characters, line breaks, and non-UTF8 characters in text fields. Attaché was built in an era where character encoding was less standardised. Modern APIs and databases reject or mangle these characters. Run a character encoding pass on all text fields before transformation.

Custom field inconsistencies. Fields that were used for different purposes at different times, or that staff filled in inconsistently over the years. Document what each custom field was actually used for before deciding how to map it.

Mapping to the target platform

Each target platform has its own data model. What maps cleanly versus what needs transformation depends on the destination.

Chart of accounts. Account structures map reasonably well across platforms, but the account type taxonomy differs. Attaché's account type codes need translating to the equivalent in Xero, MYOB, or NetSuite. If you have a large or complex chart of accounts, this is also a good time to rationalise it. Most businesses migrate a chart of accounts that has grown organically over years and has accounts that have never been used.

Customers and suppliers. Generally straightforward to map. The main differences are in payment terms structures and tax treatment. Ensure GST codes and default tax rates map correctly to the target platform's tax framework.

Transaction history. This is where most complexity lives. Historical invoices, bills, payments, and journals do not necessarily load as their original transaction types in the target platform. In many cases, historical transactions load as journal entries in the target platform's ledger, with the original document references preserved in notes fields. This means historical transaction data is preserved for audit and reporting purposes but may not be fully interactive in the same way current-period transactions are.

Open transactions (unpaid invoices, outstanding bills) at the cut-off date do load as their proper transaction types, because they need to remain actionable in the new system.

Payroll. Payroll is usually the most complex entity to migrate. Leave balances, YTD figures, STP Phase 2 data, and superannuation records all need careful handling. Many businesses run payroll on a separate system (KeyPay, Employment Hero, Xero Payroll) and the Attaché migration just needs to ensure the financial data connects correctly. If you are migrating payroll as well as financials, run it as a separate workstream with its own validation.

Test migration and validation

The test migration runs the complete ETL pipeline against a sandbox or development environment of the target platform. This is not optional. Every migration that skips test validation finds problems on go-live day.

What to validate after the test migration:

• Record counts: Do the number of customers, suppliers, and accounts in the new system match Attaché? Discrepancies indicate extraction or transformation issues
• Opening balances: Trial balance in the new system should reconcile to Attaché's closing figures at the cut-off date. This is usually the most rigorous financial validation step
• Open AP and AR: Every unpaid invoice and bill in Attaché should appear in the new system with the correct amount, due date, and contact linkage
• Historical transaction samples: Pick 50 to 100 transactions from different time periods and verify they appear correctly in the new system
• Tax codes and GST: Verify that tax treatments are correctly mapped. An incorrect tax code on historical transactions can cause reporting issues
• Custom fields: Spot-check that custom field data has landed in the right places

Document every discrepancy found. Fix at the source (the extraction or transformation scripts), re-run the affected entities, and validate again. Do not proceed to live migration until all material discrepancies are resolved.

What happens to your integrations

Every system that currently connects to Attaché needs reconnecting to the new platform. This is often the part of an ERP migration that takes the most time, because integrations are frequently undocumented.

Make a complete inventory of Attaché integrations before the project starts. For each integration, document: what system connects, what data flows which way, what triggers the sync, and what the business impact is if it breaks. This inventory shapes the integration rebuild workstream.

Common Attaché integrations that need rebuilding:

• Bank feeds: Bank feed connections are platform-specific. The new platform will have its own bank feed setup. This is usually straightforward once the accounts are active
• Payroll systems: If using an external payroll platform alongside Attaché, that integration needs rebuilding for the new financial system. Modern payroll platforms like Employment Hero and KeyPay have API connections for all major accounting platforms
• E-commerce and POS: Order data, payment reconciliation, and customer record sync all need rebuilding. Most modern e-commerce platforms (Shopify, WooCommerce) have native connectors for Xero and MYOB Advanced
• Job management systems: If your business uses a dedicated job management tool that bills through Attaché, this is usually the most complex integration to rebuild. The data model for job costing varies significantly between Attaché and modern platforms
• Custom-built integrations: Any bespoke integrations built specifically for Attaché (via ODBC or custom scripts) need full rebuilds using the target platform's API

Integration rebuilds should be scoped and tested before go-live, not after. An ERP migration that goes live with integrations still broken is not a successful migration.

Reports and what to do with them

Custom reports built in Attaché will not migrate. They need rebuilding in the target platform's reporting tools, or in an external reporting tool if the native options are insufficient.

Before rebuilding anything, audit which reports are actually used. In most long-running Attaché environments, there are reports that were built for a request years ago and have never been run since. Ask the finance team to mark up every report they use regularly versus those they have never opened. Only rebuild the ones people actually need.

For reports that need rebuilding, consider whether the target platform's native reporting can handle them. Xero and MYOB Advanced both have reasonable native reporting for standard financial reports. Complex analytical reports, cross-entity consolidations, and operational dashboards are usually better handled in an external tool (Power BI, Metabase, or a custom React dashboard) connected to the new platform via API.

Build and validate reports in the test environment before go-live. At minimum, the reports the business uses for month-end, quarter-end, and BAS lodgement should be working and verified before cutover.

Parallel running and cutover

Parallel running means processing real transactions in both systems simultaneously, then reconciling the outputs. It is the most effective way to build confidence in the new system before switching off the old one.

A minimum of one full calendar month of parallel running is appropriate for most migrations. End of financial quarter gives you a natural reconciliation point. For businesses with high transaction volumes or complex payroll, a full financial quarter of parallel running is a better target.

During parallel running, the finance team will process every invoice, payment, and payroll run in both systems. This is extra work, but it surfaces issues that test migration validation missed. Pay attention to:

• Transactions that process correctly in one system but fail or behave unexpectedly in the other
• Reconciliation differences at the end of each week
• Reports that do not match between systems
• Integration failures or data sync issues

When parallel running is complete and the finance team is confident in the new system, set a cutover date. The cutover process itself involves:

1. Final reconciliation between the two systems at the agreed date
2. Confirming opening balances in the new system match Attaché closing figures
3. Deactivating integrations pointing at Attaché
4. Activating equivalent integrations pointing at the new platform
5. Notifying all staff that the new system is now live
6. Placing Attaché in read-only mode rather than decommissioning it immediately

Keep Attaché in read-only mode for at least 90 days post-cutover. Staff will have questions that require looking up historical data, and having Attaché accessible in read-only mode is significantly easier than trying to retrieve data from a decommissioned system.

Common mistakes

Migrating too much historical data. The impulse is to migrate everything. In practice, transactions from ten years ago are rarely accessed. Set a sensible cut-off, migrate the recent history, and archive the rest. The project will be smaller, faster, and easier to validate.

Skipping the data quality pass. Loading dirty data into the new system does not make it cleaner. It makes it harder to clean, because now you have dirty data in a system people are actively using. Fix data quality in the staging environment before load.

Underestimating integration rebuilds. Integrations are often treated as an afterthought in ERP migrations. They should be scoped as a first-class workstream. An ERP go-live with broken integrations creates immediate operational problems that are visible to the whole business.

Going live at a busy period. Scheduling a cutover in the middle of BAS period, year-end, or a high-volume trading period adds unnecessary pressure. If you cannot align to end of financial year, aim for end of a quiet quarter.

Not running in parallel long enough. One week of parallel running is not meaningful validation. One full month, minimum. The first month after cutover is always when the edge cases surface.

Decommissioning Attaché immediately. There will be questions about historical data, audit requests, and legacy reports for months after go-live. Keep Attaché in read-only mode. The cost of maintaining it is minimal compared to the cost of not having it available when someone needs a transaction from three years ago.