Migrating a Legacy ERP to the Cloud Without Stopping Production

Fourteen years of transactions, custom modifications, and institutional knowledge are not easy to move. A mid-sized precision parts manufacturer had built its operations around Microsoft Dynamics NAV 2009 — a version that Microsoft had ended mainstream support for years earlier and was approaching the end of extended support. The system still worked, mostly, but it couldn’t integrate with modern IoT sensors on the production floor, couldn’t support the mobile access their field service team needed, and required a specialist consultant to make changes that should take hours.

Nematix led the migration to Microsoft Dynamics 365 Business Central over eleven months. Production ran continuously throughout. All fourteen years of transactional history migrated with full fidelity. And the new system went live with an IoT integration layer that wasn’t possible on NAV 2009.

The Situation

The manufacturer produced precision machined components for the automotive and industrial equipment sectors. With 340 employees across two production sites and a field service team of twenty-two, they ran approximately 4,200 purchase orders, 11,000 production orders, and 38,000 sales order lines per year through NAV.

The system had been heavily customised over its fourteen-year life. Forty-one custom modifications — ranging from simple report templates to complex production scheduling logic — had been built by three different consulting firms across four different NAV versions. Some modifications were documented. Many were not.

The immediate trigger for migration was the IoT initiative: the operations director had approved a capital investment in CNC machine monitoring sensors that would capture utilisation, cycle time, and fault data. The vendor’s integration APIs required a cloud-hosted ERP. NAV 2009 was on-premise, had no cloud connector, and wasn’t going to get one.

The Challenge

ERP migrations have a deserved reputation for overrunning schedules and budgets. Three factors made this engagement particularly high-stakes.

Fourteen years of customisations, not all documented. The forty-one custom modifications had to be assessed individually: which were still actively used, which had been superseded by standard NAV functionality that hadn’t existed at the time, and which needed to be re-built in Business Central’s AL extension framework. The assessment itself was a multi-week exercise.

No tolerance for production disruption. The manufacturer operated on lean inventory principles. A day of system downtime during production would cascade into material shortages, production scheduling failures, and missed customer delivery commitments. The migration plan had to guarantee continuity.

Data integrity across a messy transaction history. Fourteen years of data included records from three prior company mergers (now consolidated into one legal entity), duplicate customer and vendor records from the merger periods, and several years of data in a now-discontinued product line. Migrating raw data would migrate the mess. The migration was also an opportunity to clean it — but cleaning had to be done carefully to avoid losing the historical integrity that finance and compliance depended on.

Our Approach

Months 1–2: Discovery and customisation assessment

We conducted a line-by-line assessment of all forty-one customisations: purpose, current usage (queried via NAV’s object statistics), business-criticality, and migration path. The assessment produced three categories:

• Retire (18 customisations): Functionality now covered by standard Business Central features that didn’t exist in NAV 2009 — no migration required
• Rebuild (16 customisations): Business logic unique to the client that needed to be re-implemented as Business Central AL extensions
• Defer (7 customisations): Low-usage modifications that would be evaluated post-go-live

This reduced the migration development scope by 44% before a line of code was written.

Months 2–5: Data migration design and cleansing

The data migration strategy used a staging database approach: NAV data extracted nightly to a cleansed staging layer, transformed into Business Central’s data model, and validated against a set of reconciliation reports (GL balance reconciliation, open AR/AP aging, open production order status, inventory valuation).

Data cleansing work: 2,340 duplicate customer records de-duplicated, 890 vendor records normalised, 4,100 inactive item records archived (not deleted — preserved for historical reporting), and the discontinued product line transactions tagged for historical-access-only status.

Months 3–8: Business Central configuration and extension development

Business Central configuration covered chart of accounts mapping, dimension structure, approval workflows, production routing and work centre setup. The sixteen AL extensions were developed and tested in a dedicated Business Central sandbox environment against a copy of the cleansed migration data.

Every extension was regression-tested against the equivalent NAV customisation using parallel transaction entry: the same scenarios run in both systems, outputs compared. Any discrepancy was investigated before the extension was signed off.

Months 7–10: Parallel running and cutover planning

A three-month parallel running period: live transactions processed in NAV (system of record) and simultaneously entered in Business Central (validation). Finance reconciled both systems weekly. Discrepancies — there were eleven over the three months — were investigated, root-caused, and resolved.

The IoT integration layer was developed during months 8–10: Business Central’s API receiving production event streams from the sensor platform, updating production order progress and machine utilisation records in real time.

Month 11: Cutover

The cutover plan was designed to complete within a single weekend to avoid the complexity of mid-week cutover. Friday close: final migration extract from NAV, data loaded to Business Central, reconciliation reports run and signed off by finance. Saturday: UAT sign-off from operations, finance, and sales. Sunday buffer: reconciliation exceptions resolved. Monday open: Business Central live.

The cutover completed without incident. NAV was retained in read-only mode for ninety days for historical reference.

Outcome

The IoT integration delivered its first operational benefit in week two post-go-live: utilisation data identified a CNC machine running at 43% capacity due to unscheduled micro-stoppages. The maintenance team traced the cause to a worn fixture. Fixing it brought the machine to 81% utilisation and recovered approximately forty production hours per month.

Key Takeaways

Assess customisations before scoping the migration. Nearly half the client’s customisations were candidates for retirement — they’d been maintaining code for functionality Business Central provided natively. The assessment reduced migration scope, timeline, and cost before the project formally began.

Data cleansing is part of the migration, not a separate project. The fourteen years of accumulated data issues — duplicates, inactive records, discontinued product lines — were addressed during the migration staging process. Migrating them uncleaned would have embedded the mess into the new system permanently.

Parallel running is not optional. The three months of parallel operation caught eleven discrepancies that would have caused finance reconciliation failures in a live system. It also built user confidence: the Business Central system wasn’t an unknown quantity by go-live, it was a validated system that had been running alongside NAV for ninety days.

This engagement draws on our Innovation & Product Development services. If your organisation is running legacy ERP software that’s holding back your operations, start a conversation.