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.