Seven Strategies That De-Risk a Legacy ERP Exit
Leaving Sage or NetSuite is rarely a software decision, it is a CFO decision dressed up as an IT one. Renewal quotes climb, customisations age into liabilities, and the second-quarter board meeting starts asking why ERP is the second-largest SaaS line item. The seven strategies below are the ones we use on every Sage and NetSuite migration into Odoo to keep the calendar honest, the budget fixed, and the operations team sleeping. Skip none of them.
Octura packages these as fixed-price ERP migrations with senior engineers on every project, no junior consultants billed at senior rates.
The Six-Phase Framework With a 90-Day Legacy Read-Only Window
Every successful migration we have run follows the same six phases: discovery → mapping → configuration → data migration → parallel run → cutover. The non-negotiable that protects the project is the 90-day legacy read-only window kept live after cutover. Sage or NetSuite stays accessible for historical lookups, audit responses, and the inevitable invoice reissue. Operations writes only into Odoo from day one; the legacy box answers questions and nothing else. Without that window, finance refuses to sign cutover. With it, scope stops creeping into "rebuild every legacy report in the new system before go-live". Detail on the staging structure in how to plan an ERP migration.
Never Big-Bang on Multi-Entity Rollouts
For a single-entity, single-country business, a big-bang cutover is defensible. For anything multi-entity, multi-country, multi-currency, inter-company, it is the most common reason ERP projects miss their go-live date by a quarter. Phase by entity or by module. Sequence the smallest, lowest-risk entity first (often a non-trading holding or a small subsidiary), prove the configuration, then roll the same template onto the operational entities. Or sequence by module: finance and procurement first, sales and inventory second, manufacturing third. The first entity teaches the partner where the customisation gaps live before they bite a revenue-generating subsidiary.
Decide Deliberately What to Rebuild vs. What to Drop
The single most common source of overrun on a Sage or NetSuite migration is the assumption that every legacy customisation has to be rebuilt. It does not. The first deliverable of the discovery phase is a customisation inventory with three columns: rebuild (genuine operational need), drop (used once a year by one person, or a workaround for a legacy limitation Odoo solves natively), and defer (nice-to-have, post-go-live phase 2). On a typical NetSuite migration we drop 30–50 % of custom fields and 60–80 % of saved searches because the Odoo equivalent is standard. That deliberate "drop" list is where the budget gets saved.
Data-Cleanup Gate BEFORE Migration, Not After
Garbage in, garbage in production. Three datasets must pass a cleanup gate before they enter the migration pipeline: chart of accounts (consolidated, mapped, no orphan accounts from a 2018 acquisition), customer master (deduplicated, the same customer never appears as ACME, ACME Inc., and ACME Corporation), and item master (no obsolete SKUs, no duplicate part numbers, no inconsistent UoMs). The gate is a sign-off, not a recommendation. Without it, every reconciliation in parallel run blames the data, not the configuration, and the project loses two weeks to forensic accounting. See the cleanup checklist in migrating from NetSuite to Odoo.
Parallel-Run Protocol, Two Weeks Minimum, Reconciled Daily
Parallel run is where finance gets confidence and where most ERP projects either land or unravel. The protocol that works: two weeks minimum, both systems live, every transaction posted in both, reconciled daily (not weekly) by a named accountant. Each day produces a tolerance report, variances under threshold are noted, variances over threshold pause the run until root-caused. Fail-back triggers are written down before parallel run starts: more than three days of unresolved tolerance variance, more than 1 % cumulative GL variance, or any tax-period boundary breach. A documented fail-back path is what makes the CFO authorise cutover; without it, the answer is "another week of parallel run, please".
Fixed-Price Scope at the Start, Not Time-and-Materials
The biggest hidden risk on a legacy migration is not the technology, it is the commercial model. Time-and-materials is a budget vacuum on Sage or NetSuite exits because there is no incentive for the partner to compress scope, drop unused customisations, or finish discovery efficiently. Insist on a fixed-price scope after a paid discovery phase. The discovery deliverable is a written statement of work with named modules, named data objects, named customisations, and named acceptance criteria. Change orders happen, but they happen against a baseline, not against a blank cheque. We run every Sage and NetSuite migration as fixed-price Odoo migrations for exactly this reason.
Post-Go-Live Hyper-Care, Named Engineer, Not a Ticket Queue
The first thirty days after cutover decide whether the project is remembered as a success or a war story. Day 1 to Day 30 is hyper-care: a named senior engineer on-call for the project team, not a shared support ticket queue and not a help-desk SLA. The named engineer joined discovery, configured the modules, and ran the parallel reconciliation; they know what each transaction should look like and can triage anomalies in minutes. After thirty days, the project transitions to standard support. Before thirty days, anything other than a direct line to the build team adds days to every issue.
How to Evaluate an Odoo Partner Without Getting Burned
The features matter; the partner shipping them matters more. Eight checks separate the partners who deliver from the ones who learn on your budget:
- Official Odoo certification (Ready, Silver, or Gold), not just "we work with Odoo".
- Discovery-call person is the build person. Account-manager handoffs lose scope.
- Fixed-price scope after discovery. Time-and-materials is a budget vacuum on ERP work.
- Senior engineers on the project. Octura runs seniors only, ask any prospective partner who actually writes your code.
- Two reference customers willing to take a call. "We have many clients" without a name is a red flag.
- Vertical specialism in manufacturing. A generalist who ships one plant a quarter is not the right partner for a plant project.
- Documented multi-phase methodology. Discovery → configuration → customization → migration → go-live → hyper-care.
- Transparent published rates. "Custom quote" is fine; refusing to share a starting number is not.
The longer version is in the Odoo partner audit.
Frequently Asked Questions
The questions readers ask us most often on this topic.
What is the safest order to migrate from Sage or NetSuite to Odoo?
Follow a six-phase framework: discovery, mapping, configuration, data migration, parallel run, cutover. Keep the legacy system live in read-only mode for at least 90 days after cutover so historical lookups, audit responses, and invoice reissues never block operations. Big-bang cutovers are reserved for single-entity, single-country businesses; everything else phases by entity or by module.
Should I rebuild every customisation from NetSuite or Sage in Odoo?
No. Most overruns come from the assumption that every legacy customisation must be rebuilt. Run a customisation inventory in discovery with three columns: rebuild (genuine operational need), drop (used rarely or solved natively by Odoo), and defer (post-go-live phase 2). On a typical NetSuite migration, 30–50 percent of custom fields and 60–80 percent of saved searches drop because Odoo covers them out of the box.
Why should the data-cleanup gate happen before migration, not after?
Three datasets, chart of accounts, customer master, item master, must pass a written cleanup gate before they enter the migration pipeline. Without it, every reconciliation in parallel run blames the data instead of the configuration, and the project loses two weeks to forensic accounting. The gate is a sign-off, not a recommendation.
How long should the parallel run last?
Two weeks minimum, both systems live, every transaction posted in both, reconciled daily by a named accountant. Each day produces a tolerance report; variances over threshold pause the run until root-caused. Fail-back triggers are written down before parallel run starts so the CFO has a documented exit path.
Why is fixed-price better than time-and-materials for an ERP migration?
Time-and-materials removes the partner incentive to compress scope, drop unused customisations, or finish discovery efficiently. Fixed-price after a paid discovery phase forces a written statement of work with named modules, data objects, customisations, and acceptance criteria. Change orders happen against a baseline, not against a blank cheque.
What is post-go-live hyper-care and why does it need a named engineer?
Hyper-care is the first 30 days after cutover. A named senior engineer who joined discovery and configured the modules is on-call for the project team, not a shared support ticket queue. They can triage anomalies in minutes because they know what each transaction should look like. After 30 days, the project transitions to standard support.
How long does a Sage or NetSuite migration to Odoo typically take?
For a single-entity mid-market business, 16–24 weeks from discovery to cutover. Multi-entity rollouts run 6–12 months because each entity sequences after the prior one stabilises. The 90-day legacy read-only window runs in parallel with the next phase, not in addition to it.
Can I migrate just one module first and add the rest later?
Yes, phasing by module is the recommended pattern for businesses that cannot tolerate a full cutover weekend. Typical sequence: finance and procurement first, sales and inventory second, manufacturing third. Each phase has its own parallel run and cutover, and the legacy system shrinks in scope rather than disappearing in one weekend.
What data should I leave behind in Sage or NetSuite?
Open transactions and current-year history migrate. Historical years (often 5+ years of closed transactions, archived projects, retired SKUs) stay in the legacy system under the 90-day read-only window, and after that in a low-cost archive instance or a CSV export. Migrating every byte of historical data is the single biggest budget waste on legacy exits.
How do I handle multi-currency and inter-company on a multi-entity migration?
Configure multi-currency and inter-company on the smallest entity first, prove it on closed-month financials, then template the same configuration onto the operational entities. Inter-company reconciliation is the highest-risk surface, every multi-entity migration should reserve dedicated parallel-run capacity for it.
What fail-back triggers should be defined before cutover?
More than three days of unresolved tolerance variance, more than 1 percent cumulative GL variance, any tax-period boundary breach, or any blocked critical operational workflow (order entry, invoicing, payroll). Triggers are written down before parallel run starts and signed off by the CFO so the decision is procedural, not emotional.
Why does Octura insist on senior engineers for every migration?
Migrations punish unfamiliarity. A senior engineer who has shipped 20+ Sage or NetSuite exits recognises customisation patterns in discovery, anticipates reconciliation traps in parallel run, and triages anomalies in hyper-care in minutes rather than days. Octura staffs every migration with senior engineers from discovery through go-live, no juniors learning on the project budget.