By Hugh O. Stewart 

If you’re planning an ERP migration, you’ve probably heard some horror stories about data migration. Poorly planned ERP data migrations can drag on for months, if not years, leading to a chaotic go-live (a.k.a. cutover) followed by months of error corrections. In a worst-case scenario, the accounting team discovers they can’t produce critical reports during their first monthly close, and the entire implementation fails.   

All of these challenges trace back to five common misunderstandings about ERP data migrations. If you get your head around these issues, you can save yourself and your team a lot of frustration and unnecessary expense during your ERP transition. 

ERP Migration is a Cross-Functional Design Effort — Not an IT Project 

Many companies approach ERP migrations like a simple IT project, as if it’s an entirely behind-the-scenes technology project that doesn’t affect other departments. But ERPs aren’t just static repositories for data. An ERP tells the operational and financial story of everything happening across your business.  

IT-led ERP migrations often underestimate the level of granularity that other departments, especially the accounting and finance teams, will need from the new ERP. We’ve seen ERP implementations where the accounting team was first consulted a few weeks before go-live, at which point they discovered the migration wouldn’t support their audits because it didn’t include their subledger data. That’s a nightmare situation that could have been avoided if accounting was included in the earlier conversations about the data migration scope.   

Anyone who relies on data that flows into or out of an ERP should be involved in the earliest planning stages of an ERP migration. That might include IT, accounting, project managers, finance, HR, and more. 

Aligning your stakeholders at the beginning turns the project into a collaborative visioning exercise instead of yet another IT initiative that’s shoved down people’s throats. Teams that had a hand in designing the final configuration will have a much easier time adopting it because they were given a voice in determining how it could be designed to benefit them.  

Data Inventory Is More Important Than Data Hygiene 

Going into an ERP data migration, many teams worry about their “dirty data.” They know their system includes transactions with inconsistent tags, missing memos, or other incomplete contextual information. They may have duplicate vendors across multiple files. The data they want to migrate into one ERP may currently exist across multiple platforms, each with different data structures.  

Because of these inconsistencies, they put a lot of effort into “cleaning” their data prior to migration — reclassifying projects as active or inactive, archiving outdated vendors and customers, and deleting records they believe are irrelevant. However, in doing so, many teams inadvertently remove data that is actually relevant to the migration, which puts the whole migration at risk.  

Here’s the good news: experienced data migration teams expect your data to be full of hygiene issues. At Platform Transition, we’ve built our entire process based on this assumption. In fact, for many of our data migration scopes, we discourage teams from cleaning up their data before working with us, because we can systematically resolve many data hygiene issues during our migration process, while ensuring that no relevant data gets archived or deleted in the process.  

Instead of spending your time tidying up your data, focus on fully understanding your data. Many migration efforts run into trouble because they start loading data into the target system before they understand all of the supporting structures and relationships that should exist to receive that data. Worse, teams forget about entire workflows that rely on data that they’re unaware lives in their legacy system.  

Before you make any decisions about your ERP configuration, get to know the data that actually exists in your system. Don’t just look at your active master data lists. Export your full transaction history and work backwards to create your real master data lists. Only once you’ve identified every header or element that describes a transaction or data type that appears in your historical activity will you be able to design a configuration that’s guaranteed to support all your data and all your workflows.  

Data Mapping Involves Strategic Design Decisions 

In ERP migrations, you often have to deal with non-conforming data structures between the source and target systems. In these cases, what looks like a simple data mapping problem is often a strategic decision. 

For example, when migrating from QuickBooks to Sage Intacct, you may run into transactions that are classified as Rebate Payments, Tax Payments, or about 30 other transaction types. Sage Intacct, in contrast, only has about thirteen transaction types. To properly migrate that data and preserve all the reporting structures, you need a strategy to determine how you’ll re-classify each transaction type, if you choose to perform a subledger migration. Determining that strategy requires intimate knowledge of the target system’s reporting capabilities and data hierarchies. If you’ve never worked with the target system, you’ll probably need to lean heavily on the expertise of your VAR or data migration specialist. 

ERP Migration Is an Opportunity to Redesign Reporting — Not Just to Recreate the Past 

Even when teams take the time to understand their data, they often try to replicate the legacy system inside the new ERP. But modern ERPs don’t just offer better data security or improved user rights management, they give you the power to tell more stories with your data or understand your data in new and exciting ways.   

Thus, an ERP migration offers an opportunity to completely reimagine your reporting. Don’t just streamline your most time-consuming workflows, take a step back and ask what insights your data could tell you, but are currently impossible (or extremely impractical) to pull from your legacy system. This reporting wish list will translate into your configuration requirements — which determines the data map that you will have to fit your old data into.  

Sage Intacct is a great example of a modern ERP that offers much more flexible reporting structures than legacy ERPs. Legacy ERPs typically were only built to handle financial data. But Sage Intacct is designed to ingest data from hundreds of different sources, including non-financial data like employee headcount, number of labor hours, project names, and so much more.  

These records can be combined with financial data to calculate insights like profit per employee. Examining profit per employee trends as your company grows or shrinks or can lead to some surprising insights about productivity. 

If that’s an insight your leadership wants to monitor, you can configure a dashboard that will dynamically update that calculation with the latest revenue and cost numbers.  

Validation Needs to Start During Data Extraction — Not Just After Importing Data 

Data validation is a critical step during ERP data migrations. It’s how your team ensures that the data in the new system is trustworthy. However, many teams wait until after data is imported to begin evaluating the success of the migration. They use the built-in error detection tools inside the target system and run a few reports to compare with analogous reports in the legacy system.  

If their reports don’t match up, it can lead to loss of confidence in the data, arguments with the migration team, and possibly a lot of re-work.  

A more effective approach is to establish a shared definition of success before beginning the project — what the data should look like, how it should behave, and which reports need to reconcile between systems at the end of the effort. 

Before any data is moved, the end-user and the migration team have to agree on a validation standard that will be used to evaluate the accuracy and completeness of the migration. In most cases, the best validation standard is a report that already plays a meaningful role in your day-to-day operations. Ideally, it’s a report the finance team trusts, understands, and uses regularly to make decisions.  

Instead of waiting until after data is imported to begin evaluating the migration, the migrator should use the validation standard to prove the accuracy of the data after extraction, after any reformatting or de-duplication efforts, after uploading into the implementation environment, and finally after go-live. This maintains the end-users’ confidence in the data throughout the migration and makes it much easier to identify and resolve any errors during the process.  

Partner with an Experienced Data Migration Expert to Ensure a Smooth Migration  

The strategic aspects of ERP data migration are often the most underestimated parts of the effort. Teams assume the process is a simple transfer of data from one system to another, not realizing that it involves dozens of strategic decisions to make sure it accurately reflects the way your business operates. 

At Platform Transition, we specialize in helping organizations navigate those decisions. We work alongside your team to understand your ERP data at a transactional level, align stakeholders around a shared vision, and design a data migration strategy that preserves what matters and unlocks new capabilities.  

Schedule a meeting or request a quote to start planning your ER data migration today.