Changing ERP partners: the takeover method, illustrated with Business Central

Whether the system is SAP, Sage X3 or Business Central, an ERP project taken over by a new partner almost always follows the same script. The system works, more or less, but the knowledge of what was built has left with the previous team. It has to be recovered, including what was never written down, without interrupting invoicing, purchasing or the month-end close. The reasons for the change vary: a deteriorating relationship, a partner that was acquired, a key consultant who left, or a decision to bring part of the maintenance in-house.

A Business Central project illustrates each of these difficulties. On a Monday morning, the new partner opens the admin center. It finds three sandbox environments nobody can explain, an extension developed for the customer with no source code available, and delegated admin access that expires in ten days. The outgoing partner billed its last day of time-and-materials work the week before.

Symptoms on the ground

On any ERP, the first signals come from automated jobs that nobody monitors anymore. In Business Central, they show up on the "Job Queue Entries" page: a customer reminder run or an accounting export has been sitting with the status "Error" for weeks. The previous consultant restarted the job by hand every Monday and never mentioned it.

Next come the custom developments whose code was never delivered. In our Business Central project, an extension does appear on the "Extension Management" page, but its resource exposure policy prevents anyone from downloading its code from the environment. The new partner can run it but cannot fix it. At the next major update, in April or October, one standard object removed by Microsoft is enough to block its installation.

Business teams, for their part, have built their own workarounds. An Excel file recalculates the commissions the ERP gets wrong, and an accountant corrects a field before every invoice is posted. None of this appears in any document. It surfaces the day that person goes on holiday.

Financial, operational and human impact

The most visible cost is the time spent understanding before acting. An issue the outgoing team fixed in an hour can take two days of analysis for the team taking over, and those days are billed. When a custom development has to be rewritten for lack of source code, the bill changes scale.

Operations take the hit as well. One stopped EDI interface, or a bank synchronisation that fails without an alert, and the day's transactions are not processed. The first month-end close after the takeover often reveals the damage: the financial controller finds inventory variances that nobody can explain anymore.

For staff, the takeover feels like starting from scratch. They have to explain again processes they thought were settled, and their trust in the system drops at the very moment the new partner needs it.

Root causes and governance failures

Blaming the outgoing partner would be convenient. The reality is more shared. The original contract often provided for no reversibility clause, no delivery of the custom code and no operations documentation, and the company never asked for them while everything worked. The outgoing partner, for its part, has little interest in spending unbilled time training its successor.

The most common governance mistake is to confuse the contract end date with the takeover date. The new partner starts support with no overlap period and learns the system by handling incidents. Admin rights change hands at the last minute, sometimes after the previous partner's access has been cut off. In Business Central, this means granular delegated admin privileges (GDAP) and CSP licences, without which the new partner cannot even open the admin center.

Then there is tacit knowledge. Part of the setup rests on choices made in workshops years ago and never recorded. Only two or three key users still know why, and nobody has identified them as holders of critical knowledge.

Action plan, prevention and remediation

The takeover is negotiated before the new contract is signed. The company secures a handover period from the outgoing partner, two to six weeks depending on scope, during which both teams handle real incidents together. The first workshops list the companies, sites and legal entities in use, with their specific features: Intrastat, the chart of accounts of a foreign subsidiary, an approval workflow specific to one warehouse.

Mapping then covers environments, custom developments and interfaces. For each development, the team records its author, its type and where its source code is kept. In Business Central, this means separating AppSource apps from per-tenant extensions, then reviewing the AL code for objects marked obsolete, which signal the breaks to come in the next updates. Interfaces with banks, EDI, the e-commerce site or payroll are recorded with their frequency and owner.

If the system is already live, the ticket history and failed jobs say more than any file; in Business Central, Application Insights telemetry, when enabled, completes the picture. If the project is still being deployed, the diagnosis focuses instead on the state of testing in the sandbox: scenarios validated, scenarios to rerun, open issues. Each step produces its deliverable as it goes, which avoids the eighty-page binder handed over on the last day and never read.

Cutover only happens once these conditions are met:

• source code of all custom developments delivered in a repository owned by the customer;
• admin rights and licences transferred to the new partner, meaning GDAP and CSP for Business Central;
• no scheduled job in unexplained error;
• emergency procedures tested and escalation contacts known, at the ERP publisher as well as at third-party app publishers.

The cutover plan then assigns each action to an owner, with a fallback procedure. Key users receive the new support request process the day before, not the day after.

Conclusion

An ERP project takeover is won or lost before the first ticket. A company that lets support start without source code, without admin access and without a handover period is buying a risk it will pay for at the next version upgrade. In Business Central, that deadline comes twice a year. The method is only worth something if nobody skips steps.

The first measure costs nothing. Management rereads its current implementation contract, checks that it provides for reversibility and ownership of the custom code, then asks where that code is today. If nobody can answer, the takeover has already begun, without anyone having decided it.