ERP Data Migration Without the Drama: 9 Field-Tested Moves
Key takeaways
ERP data migration is not one task. It's four (inspect, cleanse, map, validate), and skipping any one is where projects go sideways.
Most ERP data migration budgets get blown by historical transaction data, not master data. Know the difference before you scope the project.
ERP data migration from Dynamics GP or NAV carries specific risks around dimensions and chart of accounts mapping that generic advice never mentions.
The partner running your ERP data migration counts for more toward the outcome than the software you're moving to.
ERP data migration articles all tend to say the same thing in the same order: clean your data, map your fields, test before go-live. All true. All thin. None of it explains what really happens once a real project is three weeks in and someone discovers a spreadsheet nobody knew existed.
We've run this process for over 400 businesses, most of them moving off Dynamics GP or NAV into Business Central. Some went smoothly. A handful didn't, and those are usually the ones that teach the most. What follows are nine things about ERP data migration that tend to get left out of the polished version of this conversation, the kind you only learn by sitting through the messy parts of a real project.
ERP Data Migration Starts With an Inventory, Not a Plan
Every project we've run started the same way: someone wanted to jump straight to mapping fields onto the new system. Don't. Before any mapping happens, you need a full inventory of what data exists, where it lives, and who relies on it day to day.
That inventory has to cover every module in your current setup, not just the accounting core, which is the same starting point we lay out in our best practices for ERP implementation at small and mid-sized businesses. The spreadsheet your operations team quietly built as a workaround counts. So does the old CRM export nobody officially uses anymore but everyone still pulls contacts from once a quarter. Build a plan on an incomplete inventory and the gaps surface midway through testing, which is a far more expensive place to find them than during planning.
Set aside a full week for this discovery phase alone, even on a small project. Interview one person from each department who touches financial or operational data, not just accounting. Warehouse leads, sales reps, and project managers often know about data sources that finance never sees, and each one belongs in the project scope from day one.
Talk Through Your ERP Data Migration TimelineChat with our team before you scope your ERP data migration. We'll tell you honestly whether it's a two-week job or a two-month one. |
ERP Data Migration Costs Come From History, Not Master Data
Master data (customers, vendors, items) is usually the easy part. Historical transaction data is where the real cost sits. Years of invoices, journal entries, and payment history don't always translate cleanly onto a new system's structure, and reconstructing that history correctly can eat far more hours than anyone budgeted for.
Our general recommendation: bring over two to three years of detailed transaction history and archive the rest in a reporting-only format. Full historical conversion is possible, but it adds real time and cost for value that rarely pays off. If your auditors need seven years of detail on hand, keep the old system running in read-only mode instead of forcing everything into the new one. We've broken down the real cost of staying on Dynamics GP versus moving to Business Central if budget is the piece holding your decision back. That single decision, made early, is often the difference between a four-week project and a ten-week one.
ERP Data Migration Timelines Depend on Decisions, Not Data Volume
A common assumption is that a bigger database automatically means a longer ERP data migration. The timeline is driven more by how many decisions your team has to make: what to keep, what to archive, how to handle exceptions, and who signs off on the final numbers.
A well-organized 50-employee distributor with clean records and a fast decision-maker can move through the full process in four to six weeks. A smaller 20-employee company with three side spreadsheets and no clear data owner can take twice that long, even with less raw data involved. Assign one internal person to own migration decisions before the project starts, using the same reasoning we cover in who should lead an ERP implementation. That single move shortens the timeline more than any technical shortcut ever will.
ERP Data Migration Needs a Cleansing Pass Before Mapping
Field mapping gets all the attention, but cleansing has to come first. Duplicate customer records, inconsistent item codes, and outdated vendor terms don't disappear just because you're moving to a new system. They get imported along with everything else, and then someone has to fix them from inside the new platform, which is a slower and more disruptive place to do it.
A practical cleansing checklist before mapping begins:
Merge duplicate customer and vendor records
Standardize item numbering and units of measure
Close out or clearly flag inactive accounts
Confirm tax codes and payment terms still reflect current policy
Remove test or placeholder records that accumulated over the years
Verify addresses and contact details against current records, not the ones from five years ago
Skip this step, and the result tends to be a new system that looks clean on the surface but carries the same clutter underneath. It's a false sense of a fresh start, and it usually resurfaces within the first few months of using the new platform.
For a deeper walkthrough of this exact step, our post on preparing data for Business Central covers chart of accounts review, opening balances, and tax field cleanup in more detail than we have room for here.
ERP Data Migration From Dynamics GP or NAV Has Its Own Traps
If you're moving off Dynamics GP or NAV specifically, generic advice on this topic misses some platform-specific issues entirely. The chart of accounts structure in GP doesn't map one-to-one onto Business Central's dimension model, and a rushed ERP data migration will flatten reporting categories that used to give you useful detail.
Dimensions are the biggest trap. GP users often rely on account segments to slice reports by department, location, or project. Business Central handles that same need through dimensions instead, and if the mapping isn't planned carefully, you either lose that reporting granularity or end up duplicating it in a way that makes reports harder to read, not easier. We've compared Business Central and Dynamics GP directly if you want the fuller technical picture before your team starts mapping fields.
Item and inventory data carries a similar trap. Unit-of-measure conversions that worked fine in GP sometimes behave differently once they're inside Business Central's inventory engine, particularly for manufacturers running multiple units per item. We've also answered a related question directly: whether some Dynamics GP users truly can't move to Business Central, which comes up often once teams see how much dimension planning is involved.
ERP Data Migration Testing Should Break Things on Purpose
Testing usually means checking that account balances match between old and new systems. Necessary, but not sufficient. Genuine testing means running your actual month-end close process against the converted data, not just spot-checking a handful of report totals and calling it done.
Pull a few edge cases on purpose: a customer sitting on a credit balance, a vendor with a partial payment applied, an item showing negative quantity on hand. If the conversion handles those correctly, it'll handle routine transactions without issue. If it doesn't, you want to find out during a test cycle, not during your first real close in the new system, with real deadlines attached.
Give this phase at least two full weeks and involve the people who use the reports every day, not just IT. A finance team member running a real reconciliation catches things a developer checking record counts never will.
Our complete ERP implementation checklist has a fuller testing sequence if you want a step-by-step version of this phase. Document every discrepancy you find during testing, even the small ones, and track whether it traces back to the source data, the mapping rules, or the new system's configuration. That log becomes useful again during the first live close, when a similar-looking issue shows up and someone needs to know whether it's already been solved once before.
ERP Data Migration Success Depends on Who's Running It
This is the part vendor content skips entirely, because vendors sell software, not migration expertise. The single biggest factor in whether the project goes well is whether the person running it has done this exact kind of conversion before, on your specific source system.
A consultant who's only worked with clean demo data will underestimate how messy real production data gets, and that gap tends to show up midway through a live project rather than during the sales conversation, when it's harder and more expensive to fix. We put together 8 questions to ask before signing with a Microsoft Dynamics 365 partner specifically to help with this evaluation, and our Business Central partner checklist for growing companies walks through what a partner's actual scope of work should look like.
Our support plans exist partly because problems don't always surface on day one. They show up three months later when a report doesn't tie out, and having someone who already knows your data helps close that gap fast, without starting a fresh investigation from scratch.
When a Business Central implementation goes sideways, the fix usually isn't more software. It's someone who's seen the failure mode before. Here's what that looked like for one of our clients:
"A few years ago, we engaged Shannon Mullins to help us decide how to proceed with our Business Central implementation. We contacted her and within hours we were on the phone discussing details with her and her team. Shannon was able to quickly assess the situation and come up with a game plan to get us back on track. She is a consummate professional and her knowledge of Business Central is truly impressive. Thanks to her we were put back on track within days."
John, Director of Operations
That kind of fix comes from experience, not just certification. Hear Shannon talk through her own approach to Dynamics 365 migrations, and why she built A BC Consulting Group around exactly this kind of hands-on troubleshooting:
Talk to our team before you commit to a partner. Book a free consultation and ask us the hard questions about your specific ERP data migration. We'd rather you ask us now than discover a bad fit three months into a project.
ERP Data Migration Doesn't End at Go-Live
Plenty of projects get treated as finished the moment data lands in the new system. It isn't finished at that point. The first full month-end close, the first quarter-end tax filing, and the first year-end report are all real tests of whether the conversion worked the way it was supposed to.
Budget time and attention for the first 60 to 90 days after go-live, and keep our year-end close tips and tricks for Business Central close by once you hit that milestone for the first time. Reconcile old-system reports against new-system reports for at least one complete close cycle. Small discrepancies that seemed harmless during testing sometimes compound once real transaction volume flows through daily, especially in businesses with high invoice counts or complex inventory movement.
Assign someone specifically to own this reconciliation window. Without a named owner, minor issues sit unresolved until they become bigger ones.
You Deserve ERP Data Migration without the DramaNo need to sit at your computer, frustrated, struggling to make a decision. You’re one call away from the answers you need and the direction you can go in to make the best moves for your business. |
ERP Data Migration Is a Business Decision, Not Just an IT One
One point deserves to be said plainly: these decisions get made by IT teams far more often than they should be. Finance needs a seat at the table for what historical data gets kept versus archived. Operations needs input on what item and inventory data reflects how the business runs today, not how it ran five years ago when the last system was set up.
A project built entirely by IT, without input from the people who'll use the reports afterward, tends to produce a technically correct system that doesn't answer the questions the business needs answered. Building a small cross-functional team, even just people from finance, operations, and IT, changes that outcome, which is part of why ERP self-implementation works well for teams that want that ownership from day one. If you'd rather have an experienced third party lead that coordination, our Business Central development team can help translate business requirements into the technical build without losing anything in the handoff.
Putting These ERP Data Migration Lessons to Work
None of the nine points above are complicated on their own. Together, they add up to the difference between an ERP data migration that quietly succeeds and one that quietly creates six months of cleanup work nobody budgeted for. The pattern we see most often isn't a single dramatic mistake. It's three or four small shortcuts stacking on top of each other: a skipped inventory step, a rushed cleansing pass, a partner who's never touched your specific legacy platform before.
If you're early in planning an ERP data migration off Dynamics GP or NAV, the best next step is usually a short discovery conversation rather than a full project kickoff, the same starting point we recommend in our roundup of top ERP consultants in Nashville. It gives you a realistic scope, a real timeline, and a chance to catch the platform-specific traps described above before they cost you anything. That's a far cheaper place to find problems than three weeks into a live migration.
If you want to talk more, or have additional questions about your own timeline, budget, or legacy system? Book a free consultation and we'll give you a straight answer, even if that answer is to wait six months before starting.
Frequently Asked Questions About ERP Data Migration
What is ERP data migration?
It's the process of moving business data, including customer records, financial history, and inventory information, from a legacy system into a new ERP platform. It typically follows four stages: inspection, cleansing, mapping, and validation.
How long does ERP data migration take?
Most projects take four to twelve weeks, depending on data volume, how many decisions need to be made about what to keep, and how clean the source data already is. A small, organized business often finishes faster than a larger company with fragmented systems, regardless of total record count.
What data should I bring into a new ERP system?
Bring current master data (active customers, vendors, and items) along with two to three years of detailed transaction history. Older historical data can usually be archived in a read-only format rather than fully converted, which keeps the project on time and on budget.
How much does ERP data migration cost for a small business?
Cost depends heavily on data quality and volume rather than company size alone. A business with clean, well-organized records will spend far less on an ERP data migration than one with years of duplicate records and inconsistent formatting, even if the two companies are similar in size and industry.
What's the biggest risk when moving off Dynamics GP or NAV?
The biggest risk is losing reporting detail during the move from account-segment structures to Business Central's dimension model. Without careful mapping, an ERP data migration from GP or NAV can flatten years of department- or project-level reporting that finance teams rely on for daily decisions.
Comments