By Hugh O. Stewart 

When migrating accounting transaction data from a legacy system into a cloud-based ERP like Sage Intacct, validation is the mechanism that gives you confidence that the data now living in your new system is complete, accurate, and usable. 

Without a clear validation standard established at the outset of a migration project, it’s nearly impossible to evaluate success objectively. Teams often rely on the built-in error detection tools inside the target system, assuming that a clean import means the data is correct. Unfortunately, those tools can only detect formatting or configuration errors. They can’t tell you whether transactions were lost during the transfer, whether values were altered, or whether dimensions attached to transactions were dropped or misapplied. 

To gain real confidence in your data, you have to validate it yourself. That means deliberately confirming that the new system contains all of the data you intended to move over, with all of the dimensions and structures you intended to create.  

How to Establish a Validation Standard During an Accounting Data Migration 

Validation starts with alignment between your Sage Intacct implementation team, your internal team, and your accounting data migration partner. Before you or your migration partners extract any data, you need to agree on a shared standard that all teams will use to judge the success 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 your finance team trusts, understands, and uses regularly to make decisions.  

Prior to the migration even beginning, it is helpful to run the report that will serve as the agreed-upon validation standard in the legacy system, and ensure that the transactional detail from the raw extracted data matches the validation standard. This step removes any doubt as to any potential corruption issues that can exist in the source data and reduces the variables in detecting and correcting any errors found later in the migration process. After the migration is complete, you’ll rerun the agreed-upon report in both the legacy system and the target system for the same cutoff date. If the balances match (accounting for any dynamic mapping decisions), the validation passes. 

Which report you use depends on the scope of the migration. For Historical General Ledger (GL) Detail Migrations, the Trial Balance is often the most effective starting point. It’s standardized, difficult to misconfigure, and touches every relevant account.  

Once the trial balance is validated, teams that want additional assurance can move to the GL Detail report. By examining the GL Detail Report in the target system and comparing it to the corresponding report in your legacy system, you can confirm that individual transactions landed in the correct accounts, carried the right dimensions, and preserved contextual details like memo lines, description fields, and reference information. 

For Historical Subledger (SL) Migrations, reports like AP Aging Detail are often the appropriate validation standard to start with. These reports tell the story of vendor activity over time and make it easier to see whether all related migrated transactions balance correctly. A secondary validation report, such as the AP Ledger in Sage Intacct (the analog of the Vendor Balance Detail Report in QuickBooks), can provide additional validation of transaction-level detail. 

In more complex environments, it’s also important to validate balances by dimension. Even if overall totals match, misapplied dimensions can undermine your reporting after Go-Live (the day you begin operating in Sage Intacct). 

One important caveat: validation only works if the data that flows into the reports stays static throughout the whole migration. During an active migration, if an accounting team member (or a third-party integration) enters new transactions into the legacy system during what we call The Active Migration Period, it will change the balances on the validation standard, and cause them to deviate from the balances that will show up on the corresponding report in the other system — essentially breaking your validation standard.  

That kind of “validation pollution” is one of the most common sources of confusion during validation testing, and it’s something that needs to be actively managed during the project. A similar source of data migration destabilization can occur if you inadvertently introduce data to the target system during the same period. We provide guidelines to all of our data migration customers to make sure their teams don’t inadvertently break our shared validation standard. 

Common Validation Methods Used in Data Migrations 

Once a validation standard is defined, there are several practical methods teams use to confirm data accuracy. 

Record Counts 

Count-based validation is often a first pass technique in a validation effort. Comparing the number of vendors, customers, transactions, or records before and after migration can quickly surface missing or duplicated data. However, a count validation can’t reliably catch data that was altered. 

Balance Checks  

Balance-based validation checks look for any discrepancies between the balances on the validation standard produced in the legacy system and the target system. If the numbers on these trusted reports match for the same cutoff dates, you can often trust that no transactions were lost or duplicated during the migration. 

Spot Checks 

After you’ve performed record count and balance checks, spot checks can add another layer of confidence to your migration results or uncover missing details that add meaning to your data. Reviewing a representative sample of records can help uncover issues that don’t affect totals, such as missing fields, blank dimensions, or entire categories of data that didn’t migrate the way you expected. 

Workflow Validation 

The last test you can consider performing during a data migration validation is a workflow test to confirm that Sage Intacct is configured to use that data the way your team expects. Data that looks correct in a database could still show up incorrectly in your key reports if the software isn’t configured properly, or if contextual fields were accidentally deleted from transactions during the migration.  

Testing key workflows confirms that the data was entered with all the elements necessary to support the processes your team relies on. An example includes checking a sales order conversion in Sage Intacct where the sales order may look correctly imported, but when the conversion of a line of the sales order occurs, the conversion fails because the configuration was not set up for the data, or the items being referenced do not exist in the transaction definition. Discovering a workflow failure like that during the migration validation step can make a huge difference in a successful transition during the Go-Live period. 

What Is Validation Testing? 

Validation testing happens before data is loaded into a production environment. Its purpose is to confirm accuracy without risking corruption of your live system. 

In many data migration projects, testing is done with sample data only. That approach can confirm whether a system behaves the way it was designed, but it doesn’t validate the completeness or accuracy of a full historical migration. Sample data can’t always surface edge cases or formatting issues that can trigger dozens or even hundreds of errors when you load the full dataset. 

We take a more thorough approach to validation testing. We validate all of your data in an implementation or sandbox (test) environment before we create anything in production. That allows us to evaluate both the functionality of the system and the integrity of the migrated data at the same time. If we find any errors, we resolve them before we ever import any data into your production environment.  

When Should Validation Happen in a Data Migration? 

Validation isn’t a single checkpoint at the end of a project. It’s an ongoing discipline. 

Our quality assurance process includes five validation steps in our 10-step migration process, because each step introduces different risks. Through experience, we’ve learned that validating early and often actually accelerates the overall migration timeline. Catching issues close to their source reduces rework and prevents downstream complications. 

The more frequently you check data quality, the smoother your project will run. 

Data Migration Validation vs. Data Migration Quality Assurance 

In a data migration project, quality assurance and validation are two similar processes, but they’re carried out by different teams, and they serve different purposes. 

At Platform Transition, quality assurance is how we check our own work before presenting it to customers. It ensures that we handled your data safely, followed our internal procedures, delivered the agreed-upon scope, and executed the migration in excellence to the best of our ability. 

Validation, on the other hand, is how you confirm that the data supports your reporting and operational needs. Ultimately, it doesn’t matter whether a migration partner met their internal standards if the data that makes it into your new system doesn’t do what you need it to do. 

That’s why customer-led validation is so important. In practice, the majority of validation issues we see aren’t caused by technical migration errors. They’re the result of decisions made during data mapping or configuration that don’t produce the expected outcome. Validation is how those issues surface, and how they get corrected. 

What Happens If You Find an Error During Validation? 

Because accounting data migrations are often complex, we anticipate that the validation step will often surface errors. That’s why we build time for reprocessing into every project. If, during your validation of the initial migration phase, you discover that a mapping decision you made doesn’t serve your needs, we’ll remove the affected data and reprocess it once at no additional charge. This happens in a significant portion of projects, usually because of strategic decisions made during configuration planning that lead to unexpected outcomes once you’re able to see the data in the implementation environment. 

If you find an error in the data itself as a result of our team’s work, we’ll reprocess the data as many times as needed to correct it, at no extra cost. 

How to Create a Validation Checklist 

A validation checklist is one of the most effective tools you can use to systematically evaluate a migration. It keeps testing focused and ensures that nothing important gets overlooked. 

That said, it’s not something we can create for you, for two key reasons. First, we have a conflict of interest. We could easily give you a checklist that would evaluate only the things we already know are correct. Second, we don’t have full visibility into what matters most to your business, so we can’t create a checklist for you that evaluates whether your migration brought over everything you need. Instead, we have recently created what we call “The Trauma List.”  It is a list of validation concerns that customers (and our team members) have had over the years, and we provide them to you for your consideration in building your own validation checklist. 

Consider vendor enrichment as an example. Sage Intacct allows you to track vendor compliance directly in the vendor record, but many legacy systems store that information elsewhere — or not at all. If you want to have that data available in Sage Intacct, you’ll need to provide it in addition to the data that we extract from your legacy system at the beginning of the project. We have no way of checking whether you remembered to provide additional data sets. That’s where a checklist can be helpful.  

Again, while we can’t create the checklist for you, we can provide a list of common errors and omissions that we’ve seen in other migrations. The examples range from categories of data to check for to programming errors that can corrupt data, such as a stray backslash or tilde in a memo field.  

We hope that the examples we can share serve as a starting point for you to create a checklist that represents what you care about, and not just the data that’s easiest to validate.  

Migrate Your Accounting Data with Confidence 

At Platform Transition, we believe the real currency in a data migration isn’t speed — it’s confidence. Our process is designed to give you clear, objective proof that your data migrated accurately and completely at every stage of the project. 

We’ve completed more than 2,800 migrations to Sage Intacct from more than 80 legacy accounting systems. With our flat-fee model and commitment to getting it right the first time, you don’t have to choose between speed and certainty. 

If you’re planning an ERP transition and want confidence in your data from day one, we’d be glad to help. Schedule your strategic exploration call or request a quote today to get started.