A practical walkthrough of the technical and operational steps involved in migrating from Attaché to a modern ERP. Data extraction, transformation, validation, integration rebuilds, and cutover.
Finance managers, IT managers, and business owners who have decided to migrate off Attaché and need to understand the actual process — not whether to move, but how.
What does an Attaché migration actually involve, step by step, and what are the common failure points?
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.
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:
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.
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.
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:
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.
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:
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.
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 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:
When parallel running is complete and the finance team is confident in the new system, set a cutover date. The cutover process itself involves:
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.
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.
Strategic planning guide: is Attaché right to leave, and which platform should you move to?
Planning guide for migrating off Microsoft Access to a modern system.
Decision framework for ageing business software.
Tell us what you are comparing, replacing, or trying to improve. We will come back with a practical recommendation and realistic scope.
