Case 03 · Connectors and migration
Thirty-two entities across a homegrown ERP and Microsoft Dynamics GP, connected and consolidated onto one ledger.
Situation
The group ran two finance systems side by side. One was written internally more than a decade earlier, held the commercial logic for a large part of the book, and had no documentation and no vendor. The other was Microsoft Dynamics GP, on premise, with a separate company database for each of thirty-two legal entities.
Nothing connected them. Consolidation happened in spreadsheets, entity by entity, every month. Both systems had to be understood before either could be connected, and no vendor had been willing to take on the homegrown side.
Approach
NAP took the homegrown system first, because it was the constraint. The Discovery Agent read the schema directly rather than working from an interview, and returned the object model, the custom fields nobody had documented, and the endpoints that were not safe to retry. One of those would have produced a duplicate payment in production. It was flagged and guarded before the build began.
Dynamics GP came second. Thirty-two company databases meant thirty-two variations of the same entity logic: different approval matrices, different intercompany treatment, and vendor records duplicated across companies with divergent terms. The Mapping Agent resolved each company scope separately rather than assuming a shared schema.
Only then was the connector built, bidirectional across both systems. Data for all thirty-two entities was migrated under the Guard, with the trial-balance gate enforced per entity rather than at the group level. No entity cleared until its own variance reached zero, and consolidation was not permitted until all thirty-two had.
Thirty-two entities meant thirty-two gates. The group close waited for the last one.