Data migration sounds simple enough: take the data out of the old system, put it into Sage Intacct, and move on.
That description is technically accurate in the same way that “move everything into the new house” describes moving day. It leaves out the boxes with no labels, the furniture that does not fit, and the mysterious cable nobody has used since 2009 but nobody is willing to throw away.
DATA MIGRATION IS A FINANCE PROJECT—NOT A FILE TRANSFER
A data migration is the process of selecting, cleaning, mapping, importing, and validating information from your legacy system in Sage Intacct. The important word there is not importing. It is validating.
Sage Intacct can accept beginning balances, journal entries, master records, and transactions through structured imports. That does not mean every record in your legacy system deserves a new home. If your vendor list contains duplicates, your customer records use three naming conventions, or your chart of accounts has codes nobody can explain, the import process will not fix the problem. It will move it—quickly and efficiently—into a newer, more expensive system.
Clean data first. Move it second.
START WITH THE DATA YOU ACTUALLY NEED
Before building import files, decide what the business needs to operate and report after go-live. We generally break migration data into three groups:
Core data: the records the new system needs to function—accounts, entities, locations, departments, customers, vendors, employees, projects, items, and other dimensions.
Historical data: prior-period financial activity needed for comparisons, trends, audit support, and management reporting.
Cutover data: open items that must continue through go-live—unpaid bills, open receivables, outstanding checks, unfulfilled orders, and similar work in progress.
That classification matters because each group has a different job. Core data supports the new operating model. Historical data provides context. Cutover data keeps real business from falling through the gap between systems.
Trying to treat all three as one giant spreadsheet usually produces exactly what you would expect: one giant problem.
CLEANUP HAS TO HAPPEN BEFORE THE IMPORT
The quality of a migration is usually proportional to the quality of the cleanup the client can realistically complete beforehand. That is the part teams underestimate.
Start with master records. Merge duplicate vendors and customers. Fill in required fields. Standardize names and IDs. Confirm payment terms, tax settings, addresses, and active or inactive status. Then move to the chart of accounts and dimensions. Decide which legacy accounts still serve a purpose, which should map to new accounts, and which should retire with dignity.
Sage Intacct relies heavily on exact IDs, dimensions, and valid references. Import headers must match the official template. Referenced records must already exist. IDs must match—including capitalization. A nearly correct ID is still wrong, which is a wonderfully unforgiving way for a CSV file to spend your afternoon.
Here’s two painful scenarios from the real world.
GTIN/barcode values arrive as 12, 13, or 14 digits, so integrations have to pad or strip leading zeros — and digit length does not tell you the unit of measure (unit vs. case vs. pallet), which is exactly the kind of "looks close enough" master-data assumption that breaks downstream.
An inbound customer order with no unit price causes the system to fall back to the item-master base price: ~$124 instead of ~$4.41 per case. The import succeeded, the number was nonsense. Both support the post's argument better than an abstract capitalization warning.
Prioritize master data over history because "bad data will cause errors due to the built-in (or customized) business logic," while historical financials are usually easy to compare unless the COA is night-and-day different. Also, consider dumping data back out to CSV and having an AI reconcile every cell against the source, twice. The diligence is worth the effort.
Use a fresh import template from the configured Sage Intacct, document every mapping decision, and test with a small sample before loading the full file.
MONTHLY NET ACTIVITY OR TRANSACTION-LEVEL HISTORY?
There is no universal right answer.
Monthly net activity means loading summarized historical changes by period, account, entity, and the dimensions needed for reporting. Transaction-level history means recreating individual historical entries at a more detailed level. Summary history takes less time, creates a cleaner opening position, and may be entirely appropriate when the primary need is comparative financial reporting. Transaction-level history supports deeper lookups and analysis, but it requires substantially more mapping, cleanup, reconciliation, and testing.
The decision should follow the business requirement—not a default habit from an implementation checklist.
Ask practical questions. Will your team need to research individual legacy transactions inside Sage Intacct? Which reports need prior-year dimensional detail? Do auditors need source-level support in the new system? How much historical data is reliable enough to migrate? How much time can the project support without putting go-live at risk?
One product detail matters here: Sage Intacct’s normal operating model records transaction detail in subledgers and summary activity in the General Ledger, with drill-down from the GL to the originating subledger records. A monthly historical journal import is not the same as recreating the original AP, AR, or other subledger transactions. If you choose summarized history, be clear about what users will—and will not—be able to drill into after go-live.
RECONCILE BEFORE YOU MOVE ANYTHING
Do not use the migration as the moment you discover the old system was out of balance.
Before conversion, tie the source data to approved control totals: trial balance by period and entity, AP aging, AR aging, bank balances, fixed assets, deferred revenue, inventory, project balances, and any other material subledger. Lock those totals for the migration cycle and retain the supporting exports.
For mapped GL history, confirm that each period balances and that mapped account totals tie back to the source. For open items, reconcile the detailed records to the related control accounts. For dimensions, verify that the totals still make sense after accounts and codes are transformed.
Reconciliation before import gives you a known starting point. Without it, every post-import variance becomes a guessing game between three suspects: the source data, the mapping, and the import. That is not detective work anyone needs during go-live week.
VALIDATE AFTER THE IMPORT—THEN VALIDATE AGAIN
A successful import message tells you that Sage Intacct accepted the file. It does not tell you that the business result is correct.
After each load, compare record counts, control totals, and key balances to the approved source. Review rejected rows and correct the underlying issue rather than patching numbers until the variance disappears. Spot-check individual vendors, customers, transactions, and dimension combinations. Confirm that beginning balances and open items landed in the correct entity, account, period, and book.
Then repeat the process with the people who own the data. Finance validates the ledger. AP and AR validate open items and master records. Operations validates projects, inventory, contracts, or other operational data. The implementation team can confirm that the import worked; the business has to confirm that the data means what it is supposed to mean.
REPORTS ARE THE FINAL EXAM
Do not wait until the first live month-end to find out whether the migrated data supports the reports leadership expects.
Build and test the balance sheet, income statement, cash flow statement, departmental reports, entity reports, budget comparisons, and other critical outputs before go-live. Run them for migrated periods. Compare them to the legacy reports. Test drill-down behavior. Confirm account groups, dimensions, signs, and period logic.
If the reports do not tie, the migration is not finished—even if every import file shows green.
KEEP A DOOR BACK TO THE LEGACY SYSTEM
Regardless of whether you choose summarized or transaction-level history, preserve read-only or archival access to the legacy system for an appropriate retention period. Someone will eventually need the original invoice image, audit note, transaction trail, or obscure report from four years ago. They always do.
But archival access answers historical questions. It does not keep the business running when a critical process hits a problem during cutover.
For the first few cycles, identify the processes that cannot afford to stop—payroll, billing, timekeeping, cash application, or anything else tied directly to keeping people paid and customers served. Build a documented fallback for those processes in the legacy system or another established workflow. That does not mean running both systems in parallel forever. It means knowing exactly what you will do if the new system, an adjacent application, or an integration is not ready on schedule.
That distinction matters. A legacy system can be a reference library for old records and an emergency operating system for critical work. Treat it as both when the risk justifies it.
Archive access lets Sage Intacct begin as a clean operating system without forcing every piece of historical baggage into it. A short-term operational fallback gives your team a way to keep moving while the first-close problems get identified and fixed.
The goal is not to make go-live look perfect. It is to make the transition controlled, explainable, and recoverable.
A CLEAN START HAS TO BE EARNED
Migration is not successful because the files loaded. It is successful when the opening position reconciles, users trust the reports, open transactions continue cleanly, and the finance team can explain where the numbers came from.
That takes cleanup before migration, validation after migration, report testing before go-live, and an honest decision about how much historical detail the business really needs.
The shortcuts do not disappear. They show up later—usually in reporting, usually at month-end, and usually when nobody has time for them.
Do the cleanup while it is still a migration task. Otherwise, it becomes your first post-go-live emergency.
THE FIRST CLOSE IT THE REAL TEST
Go-live is not the finish line. The first close is where the migration gets tested for real. Expect some bumps, and plan for them.
Keep business-critical work—such as billing scheduled for the first of the month or payroll—in the legacy system or established process for the first few days if moving it immediately would put the business at risk. Plan a top-side journal entry where necessary to account for posting-date differences and clean up the General Ledger after the transition.
And resist the temptation to run both systems in parallel indefinitely. That sounds safer, but it often means double the work without double the staff—and introduces a “super fun” reconciliation exercise at exactly the wrong time.
The goal is not to make go-live look perfect. It is to make the first close controlled, explainable, and recoverable.