Declutter, Pack, Rebuild: The Accounting Team’s Migration Manual

What a Module-by-Module Migration Looks Like

Numeric's Financial Data Platform is a full ERP replacement, and a team can start getting value from it well before the full replacement is done.

Numeric has four product lines, and each one is organized into modules.

• Close & Analytics runs your month-end on top of the ERP you already have. Close Checklist, Account Reconciliation, Flux Analysis, and Transaction Monitors centralize your GL data and close tasks in one place, so your team only touches the exceptions.
• Cash Management includes Cash Matching and JE Automation. Together they take repeat work like cash recs off your team each month and cut time from your close.
• Billing and Revenue captures each contract in the platform with its full terms and derives billing, revenue recognition schedules, and journal entries from it. When a contract or pricing model changes, every downstream invoice and transaction updates, and usage events that don't match a contract line are flagged for review. Its modules are Billing and Revenue Recognition.
• The Financial Data Platform replaces your general ledger. It stores every business event as an object and derives the accounting from it without manual journal entries, preserves full context so you can report on any dimension, and ties every number back to its source. Its modules include Agentic Subledgers, Reporting, and App Studio.

The first three product lines each work as a starting point, and the Financial Data Platform is where the rest of the ledger lands.

A phased move follows the same pattern for every module.

1. Pick the workflow where the current setup costs the most time at close.
2. Connect the source systems for that workflow and set up the accounting rules that apply to it.
3. Run it alongside your current ERP while the team compares results.
4. Once the numbers tie out across a full close, retire the old workflow and start the next module.

Numeric moved its own books the same way. The team started with billing and revenue, then brought over core financials, and has now run its finances on the Financial Data Platform for more than a year, with over 98% of cash matched automatically.

Anything you haven't moved yet keeps running where it runs today. Fixed assets and leases, for example, can stay in your current system until there's a reason to bring them over. Keeping each phase small is what makes it possible to test properly. For more on staging a rollout, see this guide to phased NetSuite implementation.

For Controllers, phasing also keeps the audit story simple. Every number in a migrated module drills back to the source record that produced it, and the workflows still in your ERP keep the controls your auditors already know.

Six Steps for Each Phase of the Migration

The fundamentals of a good migration still apply. Each one is easier to get right at the scale of a single module.

Step 1: Choose the First Module

Start where the pain is most concrete. If revenue schedules live in spreadsheets that someone rolls forward every month, Billing and Revenue is a natural first phase. If the close stalls on matching cash to invoices, start with Cash Management. If the team mainly needs reconciliations and flux analysis running on top of the ERP it already has, start with Close & Analytics.

Give the phase one owner and a finish line you can test, such as revenue schedules coming out of the system instead of a spreadsheet. A clear finish line tells you when the parallel run is done.

Step 2: Declutter the Data

Back up the source data for the module before anything moves, so you can restore it if a test run turns up problems.

Decluttering is easier at module scale. Instead of auditing every account in the ledger, the team reviews only the data one workflow touches, like open contracts and invoices for revenue or bank accounts and payment sources for cash. Remove duplicates, close out stale records, and agree on one naming convention for customers, products, and entities.

Not every historical detail needs to move, either. Here's what Parafin's Head of Accounting, John Quine, said about his team's transition to NetSuite:

“Our NetSuite migration went smoothly with help from an outside consulting firm. We chose to backfill only a few years of data and focused on monthly trial balances instead of importing every historical detail. That decision saved us time and reduced complexity.”

The same judgment applies to each module you move. Bring over what the module needs to run and report, and leave the rest accessible in the old system.

Step 3: Set Up the Accounting Rules for Each Module

This step looks the most different from a traditional migration. Instead of mapping old accounts onto a new chart of accounts, the team connects the module's source systems and spells out the accounting policy that applies to them. For revenue, that means how each contract type recognizes revenue over time. For cash, it means how a payment matches to an invoice.

Because the Financial Data Platform holds the source data exactly as it arrived, a rule can change later and the accounting recalculates from the same data. A policy set in phase one can be refined in phase three without a cleanup project.

Step 4: Run It in Parallel

Run the module alongside your current ERP for at least one full close. The Financial Data Platform posts the module's journal entries back to NetSuite, so the general ledger stays whole while the team compares the two sets of results. Any transaction it can't match to a source record shows up as an exception for someone to review, which brings gaps in the source data to the surface early.

This is how teams have adopted the Financial Data Platform so far, in parallel, with no day-one cutover.

Step 5: Tie It Out

Before retiring the old workflow, tie out the module's balances against the ERP. Compare the trial balance accounts the module touches and the subledger detail behind them. Every number in the Financial Data Platform drills back to the transaction that produced it, so tracing a difference means opening the record instead of working backward through a spreadsheet.

Your team keeps control of the books throughout. You can still post a manual adjusting entry, book an estimate and true it up later, and decide how much detail lives on each record.

Step 6: Train the Team, Then Start the Next Module

Train the people who own the module before you call the phase done. A small group learning one workflow picks it up faster than a whole department learning a new ERP at once.

Then write down what changed and what you'd do differently, and use that list to plan the next module. Later phases tend to move faster, since source systems, naming conventions, and review habits carry over from the earlier ones.

Where a Phased Migration Fits Best

A phased move onto the Financial Data Platform fits teams whose accounting is getting more complex faster than their ERP can keep up. That includes fintech, SaaS, and usage-based revenue businesses, multi-entity groups, and teams facing a NetSuite renewal or an acquisition. These are the teams whose chart of accounts tends to need redesigning most often.

Bottom Line

An accounting data migration can happen in phases your team can test. Move one module, run it in parallel, tie it out, and start the next. Each phase stays small enough to verify, and the books keep closing the whole way through.

And because the Financial Data Platform keeps the context behind every transaction, the next change in the business becomes a new tag or a new rule instead of a new migration. When the board asks for revenue by product line, your team can answer without joining data or waiting on a third party.

To map out which module your team would start with, schedule a demo.

FAQs