Editor’s Note: A smooth ERP implementation depends on getting the data migration right. For a recent implementation project, Anchor Group led the implementation and worked alongside OptimalData Consulting, a trusted data migration specialist and partner, to lead the migration and reconciliation of the client’s Oracle Fusion data as part of one coordinated implementation team. In this guest article written by Paul Giese, founder of OptimalData Consulting, he shares a behind-the-scenes look at the migration and how our teams worked together to get it right.
When a nonprofit social enterprise decided to move from Oracle Fusion to NetSuite, the calendar left no room for a soft launch. Their retail locations operate on a tight weekly rhythm, so the only viable cutover window was a single weekend. Go dark Friday night after the last store closed and be live in NetSuite by Monday morning.
That constraint shaped every decision on the project. Working alongside Anchor Group, OptimalData Consulting owned the data migration: close to 7,800 open transactions and five years of financial history, all migrated within a two-day window. The plan came down to one question: what does this business actually need in NetSuite to operate on Monday?
Project at a glance
Migration: Oracle Fusion to NetSuite
Organization: Nonprofit social enterprise with retail locations
Migration window: Friday night through Monday morning
Total transactions migrated: 7,792
Account mapping: One Oracle account string separated into five NetSuite segments
Result: Live Monday morning without losing a business day
What data moved from Oracle Fusion to NetSuite?
The migration covered five years of summary journal entries plus the client's full set of open transactions. In total, OptimalData Consulting loaded 7,792 records:
- 1,228 open sales orders
- 2,345 open AR invoices
- 8 credit memos
- 881 open purchase orders
- 3,136 open AP bills
- 71 bill credits
- 123 historical journal entries
On top of the volume, the client's segment structure was encoded inside a single general ledger account string rather than tracked in dedicated NetSuite fields.
That general ledger account string was parsed into five separate NetSuite categories: GL account, department, class, location, and a custom Business Unit segment. For open sales and purchase orders, the line-level detail was mapped by item. Mapping the account string correctly up front is what let the historical financials and open activity carry the same reporting structure into NetSuite that the client relied on in Oracle.
Customer and vendor mapping was its own workstream. Only about half of the client's records matched cleanly on the first pass, and a large share of ecommerce and military-address customers had no clean match and had to be created by hand. To solve this, OptimalData Consulting used email as the primary matching key to link Oracle records to NetSuite, and the client's team worked ahead of the two-day migration window to build the missing customers and items. That preparation meant the critical weekend wasn't spent chasing records that should have already existed.
How do you sequence a weekend NetSuite migration?
Sequence a migration around operational need, not around what is easiest to load: whatever the business needs to run Monday morning goes in first. The other half of sequencing happens before the window even opens: frontload everything you can. We loaded the already-closed financial history earlier in the implementation and mapped as many items, vendors, and customer records as possible in advance, so the weekend could be spent on live migration data instead of cleanup. On this project, the migration started late Friday night, once the last store closed, and everything had to be loaded by Monday morning. The client’s controller and the OptimalData Consulting team worked through the weekend to get it done.
Sequencing also meant protecting the import queue. A single large job can run for hours in NetSuite, and this client's item catalog was big enough that a full item import could tie up the queue for the better part of a day. We deliberately kept the largest loads out of the critical 2-day migration window so they could not block the files the client actually needed for operations Monday morning.
What a good data migration sequence looks like, in three easy steps:
- Open orders first. Open sales orders and purchase orders were the priority, because the team could not operate in NetSuite on Monday without them. These went in first so the client could resume day-to-day activity the moment they opened.
- Open AP and AR next. These were loaded during the same window but treated as lower priority. The accounting team did not need every balance on day one, so this work could follow the operational data without putting the go-live at risk.
- Final journal entries after the Oracle book close. The last period's journal entries were loaded a week or two later, once the client had finished closing their books in Oracle. With the bulk of the historical financials already frontloaded earlier in the implementation, only the final close had to wait, and the numbers we loaded were final rather than provisional.
How do you reconcile AP and AR when migrating from Oracle to NetSuite?
Open AP and AR aging should reconcile to the trial balance before it is loaded into NetSuite. Oracle can maintain balances through batched subledgers, while NetSuite posts activity into a single general ledger. If the aging and trial balance do not agree before migration, those differences will follow the data into NetSuite.
For this project, the team documented the reconciliation and resolved discrepancies before loading the open balances. That made the migrated aging predictable and prevented old reconciling items from becoming brand-new NetSuite issues.
What about topside entries?
Topside adjustments (high-level accounting changes made to align financial statements) are common migration exceptions, and this project had one. The client wanted a set of topside entries added for a store that had already been closed. I worked directly with the controller to make sure those entries were loaded correctly and posted where they belonged, so the closed store was represented accurately in the historical financials.
The outcome
The client went live in NetSuite Monday morning, on schedule, with their open orders in place and operations uninterrupted. Most historical financial data had already been loaded, with the financial history and reporting structure following in a controlled sequence once the Oracle period was complete.
Takeaways for a compressed migration window
A compressed migration window is not the problem people assume it is, as long as the plan is built the right way:
- Load around day-one operational need, not load difficulty. Orders first, because the business cannot run without them.
- Frontload everything that is already final. Closed historical periods, plus item, vendor, and customer mapping, can be loaded during the implementation, well before migration. That leaves only the live open data and the final historical financials for the weekend itself.
- Parse the account string deliberately. When reporting dimensions live inside a single GL account string, that string has to be parsed into the right NetSuite segments (here, GL account, department, class, location, and a custom Business Unit) to preserve reporting.
- Tie-out open balances to the trial balance before you load. Oracle tracks subledgers as separate batches, while NetSuite posts to a single ledger. That means AP and AR aging has to reconcile to the general ledger before migration, not after. Documenting that tie-out up front is what keeps reconciling items from surfacing in NetSuite later.
- Write your assumptions down. Where source data was ambiguous, such as AR invoices with no explicit due date, we set a documented default (Net 30) so aging behaves predictably. Assumptions that are written down can be checked, versus assumptions that are buried, which can cause disputes later.
- Plan for the messy exceptions. Topside entries, closed entities, and other one-offs are normal. Surfacing them before your migration window keeps them from derailing the timeline.
Many people assume that a compressed migration window is a data-loss challenge when in reality, it is a sequencing challenge. With the data migration load ordered around what the business needs first, and the financial history tied back to the legacy closeout, a single weekend is enough to move years of data without losing a day of operations.
Paul Giese is the founder of OptimalData Consulting, Anchor Group’s trusted partner of choice for data migration expertise.