Can I change partner mid-project?

Yes, and sometimes it is the only right decision. Changing partner during a running project is not a restart from zero: an experienced team takes over where the project stands, first secures what exists, data, configuration and knowledge, and then re-establishes control. What matters is a senior-led transition.

When does a change make sense?

A change makes sense when two things come together: dates and budget are running out of control, and the existing setup does not address the causes. The second part is the decisive one. Delay alone does not justify a change, because every change costs onboarding time. Only once it is clear that the same mistakes keep running does the calculation tip.

Three signals we see regularly in practice: the status report diverges noticeably from what the business departments experience. Decisions sit unresolved across several committee rounds without anyone taking them on. And the staffing changes without knowledge being handed over. Where all three come together, the question is no longer whether, but how orderly.

What you should do first: a sober assessment, typically two to four weeks. It shows whether this is a partner problem, a governance problem or a data problem. These three need completely different answers, and only one of them is solved by a new partner.

How does a clean handover work?

A clean handover starts with securing what exists, not with building on. In concrete terms: access to all environments, the source code of the extensions, the configuration packages and the documentation, while the previous partner is still on board. In Business Central, environments and permissions are managed through the Admin Center, and this access should be settled contractually before the collaboration ends.

Source: Microsoft Learn: Managing production and sandbox environments in the admin center

Next comes recording the current state: which processes run in production, which customisations exist, which open items are documented and which are merely known. This stocktake is the point at which an orderly handover differs from a rupture. We usually allow two to three weeks for it.

Only then is responsibility taken over, and in stages: first the control, then the ongoing delivery, last the further development. A handover that takes on everything at once produces exactly the gaps it set out to avoid.

Where does the real risk sit?

The real risk lies not in the change but in changing to a team without senior accountability. Whoever takes on a project in difficulty must be able to make the decisions that were left undone. A team that only supplies capacity postpones the problem by a few months and burns the trust that a second attempt would have needed.

The second risk is loss of knowledge. If the previous partner leaves without a structured handover, the reasons behind earlier decisions leave with them. Those reasons are exactly what you need later: why was this process built this way, which requirement was behind it, what was deliberately left out. Without these answers, the new team builds assumptions into the system.

In both cases Business Central remains the target system. What changes is the control, and that stays on your side. A partner change that hands control back to a service provider repeats the original mistake.