5 Entities. 4 Countries.
4 Years of History.
One NetSuite.
How Ledger Summit migrated a $100M business with 800 employees from five disconnected accounting systems into one multi-entity NetSuite environment in just three weeks, while preserving document-level history and enabling consolidated reporting from day one.
The Short Answer
Yes, a complex NetSuite multi-entity migration can be done fast without sacrificing auditability, but only if you migrate documents instead of balances, build the subsidiary model before replaying history, and treat intercompany logic as architecture rather than cleanup.
The original state was a five-system accounting landscape with no shared data model and no shared operating rhythm.
- One entity ran in Unanet with project-driven posting logic, project dimensions, and its own customer and vendor master records.
- One entity ran in QuickBooks Online with separate account numbering, document numbering, and its own month-end close routine.
- One entity ran in Zoho Books with different tax handling, item structures, and local reporting conventions.
- One entity ran in another regional accounting system with its own chart of accounts, transaction exports, and historical document relationships.
- One entity ran in a separate legacy finance system, while intercompany tie-outs and consolidation adjustments were coordinated outside the ERP layer.
All five systems were different in dimensions, currencies, tax behavior, numbering logic, and export format, which is why the migration had to preserve original transactions and not just move ending balances.
The client had grown through geography and necessity, not through system design. Each entity used a different accounting stack, local processes were inconsistent, and group reporting depended on heavy spreadsheet manipulation. Leadership wanted one NetSuite environment with every subsidiary configured properly, every source document available, and intercompany eliminations producing clean consolidated reporting without heroic month-end effort.
Why This Migration Was High Complexity
This was not a simple trial balance import. The target state required operational continuity, original-form transaction history, multi-currency reporting, and elimination-ready intercompany architecture all at once.
Five legal entities operated across four countries. Each had its own chart of accounts logic, vendor and customer naming conventions, tax behavior, close cadence, and tolerance for missing history. That meant the classic migration pain points were all present at once: inconsistent master records, hierarchical entity mapping, fragile historical document relationships, and serious cutover risk if testing or control evidence was thin.
A summary load would have been faster, but it would have destroyed the one thing finance and auditors would need immediately after go-live: the ability to drill from a balance back to the original bill, invoice, payment, or journal entry.
That tradeoff matters more than many teams expect. In public NetSuite discussions, people often describe the same post-go-live regret in different language: "we got the balances in, but we cannot explain them anymore." It usually starts with a well-meant shortcut. Old AP and AR are parked as opening entries. Historical intercompany balances are stuffed into elimination-ready accounts without preserving their source relationships. Legacy counterparties are merged too aggressively and then no one can tell which subsidiary really owned the original transaction. The migration appears faster for two weeks and then becomes slower for the next six months.
That changed the problem statement. The project became a controlled replay of accounting history, not a balance conversion exercise.
What Usually Breaks - And What Had To Be Solved
Most failed ERP migrations do not fail because the destination system is weak. They fail because data quality, business-process ownership, and testing discipline were underestimated.
We treated the following as the real project scope, not side issues to be cleaned up later.
The failure mode in projects like this is predictable: teams focus on loading data quickly, postpone intercompany logic, under-scope testing, and accept partial history as good enough. That creates months of post-go-live cleanup, broken reconciliations, and a finance team that immediately falls back into spreadsheets. We designed against that from the first day by aligning finance, system architecture, and cutover controls around those exact risks.
The Internally Developed Migration Stack
We used four internally developed tools to compress the timeline without cutting corners.
These were internal delivery tools, not generic middleware. Each one was designed around a known failure mode in ERP migration: bad source data, broken document relationships, misconfigured intercompany logic, or rushed cutover validation.
The target state was not a dashboard. It was a controlled operating model in which five subsidiaries, one elimination framework, and four years of source history all lived inside the same NetSuite architecture.
Practically, that meant one shared subsidiary structure, one standardized chart and dimensional model, one intercompany rules framework, and one document-level history layer that finance could drill through after go-live. Consolidated reporting became usable because the accounting relationships were rebuilt correctly, not because a reporting screen was layered on top.
LedgerBridge Entity Mapper
Normalized charts of accounts, departments, classes, tax logic, and legal-entity ownership across five source systems before any transaction was moved.
Document Replay Engine
Recreated bills, invoices, credits, payments, and journals with original dates, numbers, counterparties, and subsidiary assignments instead of collapsing everything into opening balances.
Intercompany Rules Compiler
Converted cross-entity activity into standardized due-to and due-from logic and enforced elimination-ready posting behavior before consolidated reporting was tested.
Migration Control Tower
Ran batch-by-batch tie-outs from source trial balances to NetSuite, including subledger totals, FX rollups, and intercompany mirror checks before final approval.
How We Solved the Pain Points Buyers Actually Worry About
Data quality risk -> mapped and standardized first
We cleansed and standardized counterparties, dimensions, and entity ownership before the replay so the new system did not inherit duplicate records and broken reporting logic.
Historical relationships risk -> replayed intact
We recreated bills, invoices, credits, payments, and journals as linked transactions because finance needed usable history, not flattened balances that broke downstream analysis.
Intercompany risk -> designed before loading
Instead of cleaning up intercompany after migration, we built the subsidiary and elimination architecture first and standardized due-to and due-from behavior while transactions were loaded.
Testing risk -> batch-by-batch proof before cutover
Currency translation, local tax treatment, subledger totals, and intercompany mirror checks were tested in repeated load cycles so go-live did not become the first real validation event.
The result was unusual for a project this size: the data model, operational history, and reporting structure all went live together. The client did not have to choose between speed and correctness because the usual sources of migration failure were treated as design requirements, not late-stage cleanup items.
That design bias also made the project more interesting to operate. Instead of debating abstract "best practices," the team kept returning to a concrete question: if the controller clicks into this balance during the first close after go-live, what exactly will they see? If the answer was "a summary journal plus a folder of offline reconciliations," the design was not done. If the answer was "the bill, invoice, payment, credit, counterparty, subsidiary, and intercompany relationship that created the balance," then the migration logic was probably heading in the right direction.
The Full 3-Week Journey
The speed came from sequence discipline, not from skipping steps. Every phase had an exit gate. If master data, document links, or intercompany behavior did not tie, the next phase did not start.
What follows is the actual delivery path from kickoff to go-live, including the interim steps that usually stay hidden behind a generic "3-week migration" headline.
Days 1-2: Kickoff, scope lock, and source inventory
We cataloged every source system, transaction type, reporting dependency, and owner across the five entities. The first hard decision was scope: four years of history, document-level migration, and no fallback to summary balances.
Challenge: each entity described the same accounting objects differently and exported data in a different format.
Resolution: we built a migration register that listed every object to be moved, the extraction source, the business owner, and the proof required before sign-off.
Days 3-4: Canonical data model and master data cleanup
We created one crosswalk for accounts, departments, classes, locations, counterparties, currencies, and tax behavior so the five ledgers could land inside one NetSuite structure without ambiguity.
Challenge: the same vendor or customer often appeared under multiple names, IDs, and legal entities.
Resolution: LedgerBridge Entity Mapper assigned one canonical record, preserved aliases from source systems, and locked entity ownership before transaction replay began.
Days 5-6: NetSuite subsidiary and intercompany architecture
Before loading history, we configured the target OneWorld structure: subsidiaries, dimensions, intercompany accounts, currency rules, and elimination-ready behavior for consolidated reporting.
Challenge: local entities had different operating assumptions for currencies, taxes, and due-to/due-from activity.
Resolution: we set the target design first and forced all replay logic to conform to that design instead of importing inconsistent legacy behavior into NetSuite.
Days 7-9: Historical replay prototypes and dependency sequencing
We did not dump the full history into production. We ran representative dry runs in controlled batches: master data first, then bills and invoices, then credits and payments, then journals and intercompany activity.
Challenge: document relationships break quickly when partial payments, credits, and reopened items are loaded out of order.
Resolution: Document Replay Engine loaded transactions in dependency order and preserved original dates, numbers, statuses, and relationships so history stayed usable after migration.
Days 10-12: Validation, tie-outs, and elimination testing
Once prototype loads were stable, we scaled into full historical loads and ran entity-by-entity proof: trial balance tie-outs, subledger reconciliations, FX rollups, and due-to/due-from mirror checks.
Challenge: minor rounding differences, one-sided intercompany postings, and local posting exceptions can distort consolidation even when entity balances look correct.
Resolution: Migration Control Tower and Intercompany Rules Compiler were used together to catch breaks at batch level before the client saw them in consolidated financials.
Days 13-15: Delta load, cutover, and go-live stabilization
After the rehearsal cycle, we executed the final delta extraction for transactions created between testing and cutover, loaded the remaining history, ran final validations, and delivered the first live consolidated outputs from NetSuite.
Challenge: the business could not tolerate a long blackout window or a prolonged post-go-live cleanup period.
Resolution: we used a narrow cutover window, preapproved sign-off checkpoints, and live issue tracking so the client entered production with reconciled balances, usable document history, and confidence in the first close cycle.
What Made 3 Weeks Possible
Three weeks was only possible because the project was run as a sequence of control gates, not as a long customization program.
There was no open-ended design cycle, no attempt to preserve every local habit, and no assumption that go-live would somehow reveal the truth. The team made architecture decisions early, normalized data aggressively, replayed history in dependency order, and refused to advance until each entity and each intercompany layer tied out.
That is why the project could move fast without becoming reckless. Every day had a deliverable, every batch had evidence, and every week ended with a narrower risk profile than the week before.
Speed also came from being selective about where custom logic was worth it. We did not try to encode every historical oddity from the five source systems. We encoded the accounting behaviors that mattered for control, drill-down, ownership, and consolidation, then documented the edge cases that should remain historical facts rather than become permanent features of the new environment. That prevented the target NetSuite design from inheriting a museum of old process mistakes.
What Similar Teams Keep Running Into In Public NetSuite Discussions
One reason this project sequence worked is that the ugly parts were familiar. The same patterns show up repeatedly in Reddit threads, consultant forums, and practitioner Q&A: intercompany balances that never quite eliminate, opening entries that look fine until the second close, and migrated history that cannot answer basic audit questions.
Those discussions are useful because they reveal where projects become difficult in real life rather than in software demos. The issues below were not hypothetical. They are exactly the kinds of problems other teams describe when a NetSuite migration went technically live but operationally sideways.
Legacy intercompany balances can poison first close
Practitioners regularly describe loading old due-to and due-from balances directly into elimination-ready accounts, only to find that the first consolidated close is full of noise and unexplained one-sided eliminations. Our rule was simple: either migrate the document-level relationship properly or park the legacy opening position in a clearly documented structure that does not pretend to be live intercompany activity.
Open-item history breaks when payment order is wrong
Another common forum theme is partial payments, credits, and reopened documents getting imported in the wrong sequence. The balance lands, but the transaction history becomes nonsense. That is why replay order mattered so much here: bills and invoices first, then credits, then payments, then journals and intercompany adjustments, with relationship checks after each layer.
Counterparty cleanup has to preserve aliases, not erase them
Teams often discover too late that "duplicate vendor cleanup" can destroy traceability if source aliases are removed instead of mapped. In this project the canonical master record won, but source names and IDs were preserved as searchable aliases so finance could still trace legacy exports, emails, and payment references back to the new NetSuite record.
FX and tax are not polishing tasks
Community threads around failed migrations often make the same confession after the fact: foreign currency translation and local tax rules were treated as cleanup work. We treated them as entry criteria for go-live. Currency source, rate date, tax behavior, and entity ownership had to be right before the history was allowed to scale.
That public pattern-matching was helpful because it kept the delivery team honest. If a design choice would have produced the same symptoms other teams complain about later, it was usually the wrong design choice now. In other words, the migration was not just built to pass cutover. It was built to avoid becoming a future cautionary tale.
Before vs. After Migration
What the Client Actually Got
for all 5 entities
preserved in ERP
to go-live
ready to use
The headline is speed, but the deeper win was strategic. The client no longer had five local truths and one fragile consolidation workbook. They had one accounting backbone, one subsidiary architecture, and one place where finance leadership could answer questions without first assembling data by hand.
That foundation directly enabled the next phase of work: turning a clean but still basic NetSuite setup into a fully integrated finance operating system with API bridges, automated schedules, and close acceleration. That second phase is covered in our NetSuite API integration and automation case study.
Public Tools Built From the Same Problems
GL Detail Analyzer
Use ledger-level transaction detail to identify outliers, broken mappings, and unusual movement before or after a migration.
Intercompany Elimination Checker
Spot mismatched intercompany balances and test whether your elimination logic will hold up during consolidation.
Intercompany Balance Checker
Validate mirrored due-to and due-from activity before close rather than finding breaks after consolidation fails.
Chart of Accounts Compliance Checker
Pressure-test account structure and naming consistency when multiple entities or legacy ledgers are being normalized.
Foreign Currency Translation Tool
Review translation effects when source data spans countries, currencies, and reporting layers.
Multi-Currency P&L Translator
Translate multi-entity operating results into one reporting view without waiting for a larger system project.
Planning a NetSuite migration with real history, not summary balances?
We can map the entity model, historical data strategy, and intercompany design before you commit to a risky cutover plan.
Get a free workflow analysis →Control Gates Across the 3 Weeks
Days 1-3: Scope and target state
Source inventory, migration boundary, canonical dimensions, and target subsidiary rules approved before data movement started.
Days 4-6: Cleanup and architecture
Master data normalization, OneWorld subsidiary setup, currency and tax mapping, and intercompany framework locked.
Days 7-10: Replay and dry runs
Document-level history replayed in dependency order with test loads for bills, invoices, payments, credits, and journals.
Days 11-15: Proof and go-live
Trial balance tie-outs, elimination testing, final delta load, cutover sign-off, and first consolidated reporting in production.
"The timeline looked unrealistic when we started. Three weeks later we had five entities, four years of history, working intercompany eliminations, and consolidated reporting inside one NetSuite environment."
Frequently Asked Questions
Need a NetSuite migration that survives first close?
Book a free call. We will map the subsidiary design, data replay strategy, and intercompany control points you need before migration risk turns into post-go-live cleanup.
Book a free call →