Accounting systems · Migration planning
Accounting systems migration planning.
Moving from one accounting system to another — in any direction — is a project, not a button. The risk isn’t the new software; it’s deciding what actually moves, how much history comes with it, when you cut over, and how you prove the new books tie out afterward. This is the platform-agnostic planning layer: the decisions you make before any data moves. For the concrete QuickBooks execution path, the migration silo below carries the step-by-step. Independent firm, not affiliated with Intuit Inc.
Accounting systems migration planning is the scoping and sequencing work done before you move your books from one accounting platform to another — deciding what carries over (chart of accounts, customer and vendor lists, item lists, transaction history, open invoices and bills, payroll and integrations), how much historical data to bring versus archive, when to cut over, and how you’ll validate that the new system balances against the old one. A good plan is platform-agnostic: the same decisions apply whether you’re moving between desktop and cloud, between two cloud platforms, or off spreadsheets entirely. The plan is where migrations succeed or fail; the data move itself is the easy part once the scope, cutover date, and validation method are settled.
Reference maintained by the Certified QuickBooks ProAdvisor team at TechBrot Inc., an independent firm — not Intuit, and not Intuit’s official software support. Not affiliated with Intuit Inc.
Migration planning, in five questions.
What is accounting systems migration planning?
It’s the scoping and sequencing work done before you move your books from one accounting system to another — deciding what carries over (chart of accounts, customer/vendor and item lists, transaction history, open invoices and bills, payroll, integrations), how much history to bring, when to cut over, and how you’ll prove the new system balances against the old one. The plan is where migrations succeed or fail; the data move itself is the easy part.
What data actually moves in a migration?
Typically the lists (chart of accounts, customers, vendors, items), the open items (unpaid invoices and bills, undeposited funds), the opening balances as of your cutover date, and as much transaction history as you choose to bring. Integrations, payroll, sales-tax settings, and recurring templates are rebuilt or reconnected rather than copied. What moves is a decision, not a default — bringing everything is often the wrong call.
How much history should I bring over?
Only as far back as you genuinely need it live. Many businesses migrate balances plus the current fiscal year (and sometimes the prior year for comparatives) and archive older detail in a read-only copy of the old system. More history means a larger, riskier, slower migration that’s harder to reconcile — so the question is what you’ll actually use, weighed against any tax or audit retention you need to keep accessible.
When should I cut over to the new system?
The cleanest cutover is the first day of a new accounting period — the start of a month, quarter, or fiscal year — so the old system holds whole closed periods and the new one starts clean. Avoid cutting over mid-period, during payroll runs, or across a tax deadline. The date drives everything else: opening balances, how history splits, and when you stop entering in the old system.
Do I need to run both systems in parallel?
For anything beyond a tiny file, yes — running a short parallel period (often a few weeks to a month) and reconciling the two lets you catch differences before you trust the new books and retire the old ones. Skipping the parallel run is the most common reason a migration looks done but the numbers quietly don’t tie. It’s the validation step that turns a data move into a finished migration.
What “migration planning” actually means.
A migration is moving your accounting from one system to another — from desktop software to a cloud platform, between two cloud platforms, or off spreadsheets into real accounting software. Migration planning is everything you decide before any data moves: which lists and balances carry over, how far back the history goes, what date you stop entering in the old system and start in the new one, and how you’ll prove the two agree. Almost every painful migration we’re asked to rescue went wrong in the planning, not the export — the wrong cutover date, history that didn’t reconcile, open invoices that vanished, or a chart of accounts that came across as a mess.
The decisions are largely the same regardless of which platforms are involved, which is why this page is deliberately platform-agnostic. What it doesn’t cover is the click-by-click export and import for a specific tool — that’s execution, and for QuickBooks specifically the migration silo linked below carries it. Think of this as the blueprint and that as the build. And as always, anything to do with the software vendor’s own account, subscription, or billing stays with the vendor; what we plan and execute is the accounting inside your books.
What a systems migration involves.
A migration is the sum of these decisions — the planning steps below work through them in order, so settling each one in sequence is what keeps the move predictable.
The lists and master data
Chart of accounts, customer and vendor records, item and service lists, employees, classes or tracking categories. These are the backbone, and migrating a messy chart of accounts just moves the mess. Deciding what to bring, what to merge, and what to retire is the first scoping decision — and often the most valuable cleanup of the whole project.
Open items and opening balances
Unpaid customer invoices, open vendor bills, undeposited funds, and the account balances as of your cutover date. These have to land in the new system precisely — if open invoices don’t carry across, you can’t collect against them, and if opening balances are off, nothing reconciles. This is the part that most often goes wrong when a migration is rushed.
Transaction history (how much)
How far back the detailed history comes versus what gets archived in the old system. More history is heavier, slower, and harder to reconcile; less history means looking up older detail elsewhere. The right line depends on what you’ll actually use and what tax or audit retention you need to keep accessible — not on bringing everything by default.
Integrations and connected apps
Bank and credit-card feeds, payroll, payment processing, point-of-sale, e-commerce, expense apps, and reporting tools. These rarely migrate — they’re reconnected and re-tested in the new system. Each connection is a small project of its own, and forgetting one until after cutover is a common source of post-migration scramble.
The cutover date
The single date you stop entering transactions in the old system and start in the new one. It drives the opening balances, how history splits, and how disruptive the move feels. The cleanest cutover is the first day of a new period; mid-period, during payroll, or across a tax deadline are the dates to avoid.
Reconciliation and validation
The proof the new system matches the old one — trial balance, key account balances, open A/R and A/P, and a handful of core reports reconciled side by side, usually across a short parallel period. This is the step that turns “the data moved” into “the migration is done,” and skipping it is why so many migrations quietly don’t tie.
How to plan an accounting-systems migration.
Six steps, in order. Each one settles a decision the next depends on — skip the early ones and the move drifts. If the existing books won’t reconcile before you start, stop here and clean up first.
Clean up the existing books first
A migration carries across whatever state the old books are in — so reconcile bank and credit-card accounts, clear stale open items, fix a sprawling chart of accounts, and make sure the trial balance is trustworthy before anything moves. Migrating clean books is straightforward; migrating a mess just relocates the problem and makes it harder to find.
Scope what moves and what gets archived
List every category of data — lists, open items, opening balances, history, integrations — and decide for each whether it migrates, gets rebuilt, or stays archived in the old system. Write it down. This scope is the contract for the whole project; everything that follows depends on it being explicit rather than assumed.
Choose the cutover date and how much history
Pick a cutover at the start of a clean period — a month, quarter, or fiscal year — and decide how far back the detailed history comes versus what you archive. These two decisions set your opening balances and the size of the move, so settle them before any export, not during it.
Prepare and map the data
Export the lists and balances, map old accounts and fields to the new system’s structure, and standardize names and formats so nothing imports as a duplicate or a mismatch. This is where a careful mapping pays off — a clean map means the import lands right the first time instead of needing rework after cutover.
Run a parallel period and validate
After the data is in, run both systems side by side for a short period and reconcile them — trial balance, key account balances, open A/R and A/P, and core reports. Investigate every difference until the two agree. Reconnect and test integrations during this window so nothing is discovered broken later. Don’t trust the new books until they tie.
Cut over, then reconcile the first close
On the cutover date, stop entering in the old system and switch fully to the new one. Run the first month-end close entirely in the new system and reconcile it as you normally would — the first clean close is the real confirmation the migration held. Keep the old system archived and read-only for history and audit access; don’t delete it.
When to bring in a pro to plan it.
Open items or balances are involved
If the move has to carry unpaid invoices, open bills, or precise opening balances — not just a fresh start — the margin for error is small. Getting open A/R, A/P, and the trial balance to land exactly is detailed work, and an error here means you can’t collect, can’t pay, or can’t reconcile. That’s a planned, scoped job.
The existing books are behind or messy
If the old books aren’t reconciled, the chart of accounts is a sprawl, or there are stale open items, the migration will carry all of it across. Cleanup has to happen first — and that’s a fixed-fee scope of its own ($1,500–$15,000+ depending on how far behind) before the move can even be planned properly.
History, payroll, or integrations are in scope
Bringing multiple years of history, migrating mid-payroll-year, or reconnecting a stack of integrated apps turns a simple move into a real project with sequencing risk. When several of these are in play at once — or a tax deadline is near the cutover — planning it with a ProAdvisor is far cheaper than unwinding a rushed migration.
Moving systems and want the plan checked first?
A Certified ProAdvisor scopes what moves, sets a realistic cutover, and decides how much history is worth bringing — a planned migration is a fixed-fee project scope; cleanup runs $1,500–$15,000+ if the existing books need work before they can move. Independent firm.
A Certified ProAdvisor plans the move and proves the numbers tie.
Exporting and importing data is the part software does. The part that protects the business is everything around it: deciding what carries over and what gets archived, cleaning the existing books so they reconcile before they move, choosing a cutover date that doesn’t strand open invoices or split a tax period awkwardly, running a parallel period so nothing is trusted blind, and reconciling the new system against the old until balances, open items, and key reports agree. A Certified QuickBooks ProAdvisor with active Online and Desktop certifications plans that against a written scope and validates the new books before the old system is retired. Independent firm — not Intuit, and not any platform’s software support; a vendor account, subscription, or billing matter stays with that vendor.
Free
discovery call first — we scope before we quote
Fixed-fee
planned migration project, with a written scope
Independent
Certified ProAdvisor firm — not Intuit, not any platform’s support
What people ask about planning a migration.
Is this Intuit’s official support?
What’s the difference between migration planning and the actual migration?
Does this apply to any accounting system, or just QuickBooks?
How much history should I bring into the new system?
When is the best time to cut over?
Do I have to run both systems in parallel?
What does a planned migration cost?
Can you fix my Intuit or vendor account during a migration?
Planning a move and not sure what should come with you?
Get the plan right before any data moves.
A botched migration is far more expensive to unwind than to plan well the first time. Start with a discovery call to scope what moves, set a realistic cutover date, and decide how much history is worth bringing. From there, a planned migration is typically a fixed-fee project scope; if the existing books need cleanup before they can move, that runs $1,500–$15,000+ depending on how far behind. Independent ProAdvisor firm, written scope before any work begins.