Take the documentation with you when you change partner

In a change of partner it is rarely the system itself that is the problem, but what only the old partner knows. Why was a particular setup chosen? Who has the source code for your customisation? Which integrations are running? This article gives a checklist of documentation you should ask for, and explains why it is wise to make the demand before you give notice. It is written for those who set the requirements, not for developers.

Customisations and extensions

Your Business Central may contain customisations in the form of per-tenant extensions built specially for you, and apps from Microsoft AppSource. Microsoft Learn describes that customisations are delivered as .app packages.

Ask who has the source code for your extensions and whether you have a right to it. That depends on the agreement. If you do not have the source code, a new partner may find it hard to fix or upgrade. Ask for a list of all installed extensions and apps with name, publisher and version.

Ask also for test descriptions, if they exist. A customisation without tests is hard to update, because nobody knows what must work afterwards.

What you should ask for

Not everything is written down. In that case ask for a walkthrough with the old partner, where the new partner asks questions. It can be recorded if both parties agree. An hour's conversation can clear up what would otherwise take days to discover.

An overview of customisations with a short description of purpose and function
Source code and access to the repository or an export, if you have the right to it
Setup documentation: number series, posting setup, dimensions, workflows
A list of integrations, what they do, and who owns the keys and connections
Scheduled runs in the Job Queue and their purpose
Role and permission setup, including permission sets
Report layouts and customised documents
A list of open cases and known errors

Integrations and access keys

Integrations to a web shop, warehouse, bank or other systems are often set up by the partner. Ask which accounts and keys they use and who is registered as owner. If it is the partner's account, ownership must be transferred or a new one created.

Microsoft Learn says that a delegated administrator cannot run scheduled tasks in the job queue, but that they can be created and made ready so that a licensed user starts them. It is therefore worth knowing who owns the jobs.

Ask for an overview of which third-party subscriptions and licences the partner has created on your behalf and who pays for them.

Agree it before you give notice

Documentation is easier to get while the cooperation is running. Ask for delivery on an agreed date and get it confirmed in writing. Ask whether there is a fee for compiling it, so it does not come as a surprise.

Check your original agreement. Does it say anything about ownership of customisations, documentation or code? If not, raise the question now.

When the new partner receives it

Let the new partner go through the material before the old agreement ends. Ask whether anything is missing. It is cheaper to get answers while both parties are still involved. See also the article on switching partner.

Make a list of what is missing and agree a date for when the old partner delivers it. Keep everything together in one place that you have access to yourself, and not only with a partner.

At Addverk

You will find information about support on the page about services and prices. Make the demand for documentation of everyone, including us, at the start of a cooperation.