Handing Over a Business-Critical App Before Its Only Maintainer Leaves

If your invoicing or payment app depends on one person who leaves next month, with an audit already in the diary, hand over in this order. First, transfer credentials and account ownership to the organisation. Second, make the source code and deployment pipeline usable by someone else. Third, write the runbook for the three things that break most often. Fourth, draw the dependency and integration map. Fifth, document a fallback for taking payment if the app goes down. Then verify the handover actually worked: a second person independently performs a deployment and a recovery while the leaver watches without touching. Finally, buy short-term senior cover for the gap rather than hoping nothing breaks in the first month.

Why does the order of the handover matter?

Because the artefacts do not expire at the same rate. Access tied to a personal account can disappear on the leaver's last day, when their account is disabled, and some of it cannot be recovered afterwards without a support ticket to a vendor who will ask for proof you own the account. Source code on a laptop leaves with the laptop. A runbook, by contrast, can still be written badly after they have gone, from logs and guesswork. So the order runs from what is lost permanently to what is merely harder to reconstruct.

The same logic applies whatever the app is built on: a custom application on React, Node.js, PostgreSQL or .NET, a Power Apps and Power Automate solution, or a Dynamics 365 environment with custom code. The platform changes where you look, not what you need.

How do you transfer credentials and account ownership without breaking the app?

List every account the app depends on, then move each one so that the organisation owns it and at least two named people can administer it. Work through the list with the leaver, because many of these accounts exist only in their memory and their password manager.

• Hosting and cloud: the Azure, AWS or other subscription, owner or administrator roles, and the billing contact.
• Domain, DNS and TLS certificates, including where renewals are sent and when each certificate expires.
• Code hosting: the GitHub, Azure DevOps or GitLab organisation, with the company as owner rather than a personal account.
• Payment provider and banking integrations: dashboard administrator, API keys, webhook signing secrets.
• Email sending, SMS, storage and any other third-party service with an API key in the app configuration.
• Databases and backups: administrator logins, where backups go, how long they are kept.
• Power Platform: environment administrator roles, flow ownership, and connections authenticated with the leaver's own account, which break when that account is disabled.
• Dynamics 365: the application users and app registrations integrations run as, and every secret expiry date.

Move shared credentials into the organisation's password vault, not a spreadsheet. Rotate secrets the leaver knows in a planned change while they are still there to help if something breaks, and test the app after each rotation. On their last day, block sign-in but do not delete the account until the inventory confirms nothing still runs as it; for Power Automate, the recovery sequence for flows owned by a leaver is on our Power Automate consulting page.

How do you make the source code and deployment pipeline usable by someone else?

The test is simple: can a second person take a clean checkout, build it and deploy it to a test environment on their own machine, with nothing but the repository and the vault? Until they can, the code is not handed over.

• Every piece of source is in the organisation's repository, including scripts, database migrations and infrastructure definitions that currently live in a home folder.
• Build and deployment steps run from a pipeline, or at minimum are written as numbered steps someone else has followed.
• Configuration is listed per environment by name, with values in the vault, so nobody has to read production settings to learn what exists.
• For Power Platform apps, unmanaged solutions are exported and unpacked into source control, and flows sit inside solutions with connection references rather than as personal flows.
• For Dynamics 365, plug-in source is in the repository and matches what is registered in production; our guide to taking over an undocumented Dynamics 365 environment covers recovering that when it does not.
• Anything that only exists in production, such as a hand-made database change or a setting edited in a portal, is written down and scripted.

What goes in a runbook for the three things that break most often?

Ask the leaver which three incidents they deal with most often, then check their answer against support tickets, chat history and logs, because people remember the dramatic failures rather than the frequent ones. Typical examples are a payment webhook failing, a nightly job that stops, an expired certificate or token, a stuck invoice run, or a user who cannot sign in.

For each of the three, write one page:

1. The symptom as the business reports it, in their words.
2. How to confirm it: which log, dashboard, run history or query shows it.
3. The fix, step by step, including commands or screens.
4. How to verify the fix worked and nothing was processed twice.
5. Who to tell, and when to escalate to a vendor or external support.

Add a fourth page that is not optional: restoring the app and its data from backup. It is the failure that happens least and costs most.

How do you capture knowledge that only exists in someone's head?

Do not ask the leaver to write a large document in their notice period. It will be late, generic and unread. Capture knowledge through work instead.

• Recorded working sessions where the successor drives and the leaver talks, rather than the other way round.
• A calendar sweep: everything that happens monthly, quarterly or yearly, such as price updates, year-end numbering resets, licence and certificate renewals, and the audit extract itself.
• The workaround list: every manual step they do so the system appears to work, like correcting a record before the invoice run.
• The people list: vendor contacts, account managers, the person in finance who notices when something is wrong.
• Questions from the successor, answered in writing in the repository, so the documentation grows from real gaps.

What should the dependency and integration map show?

One page, kept in the repository, showing everything the app talks to and everything that talks to it. For each connection record the other system, the direction, the trigger or schedule, the credential and its expiry, what the business loses if that connection is down, and who to contact on the other side. Include the scheduled jobs and the things that are easy to forget: the file a bank or payment provider collects, the export an accountant downloads, the report someone runs before the audit.

If the map turns out to be a web of undocumented point-to-point connections, that is a later project rather than a handover task; our guide to rationalising point-to-point integrations covers it.

What is the manual fallback for taking payment if the app goes down?

Write down how the business takes and records payment for a day, or a week, without the app, and who is allowed to decide to switch to it.

• The alternative route to take payment, such as payment links or a virtual terminal from your existing payment provider, or bank transfer details, with who has access to each.
• How each payment is recorded while the app is down, in one register, without ever writing down card details.
• How those payments are entered or matched back into the app once it returns, so nothing is charged or invoiced twice.
• Who tells customers, and what they are told.
• Who in finance signs off the reconciliation after the outage.

Rehearse it once with the finance team before the leaver goes, on a quiet day.

How do you prove the handover actually worked?

A handover is proven when someone other than the leaver does the dangerous things successfully, not when a document exists. Schedule two exercises in the leaver's last fortnight, with the leaver present but hands off.

• A deployment: the successor makes a small, real change and takes it from source control to production through the documented path, without asking for a password or a missing step.
• A recovery: the successor restores the app and database from backup into a test environment and works through one of the three runbook incidents, simulated.

Every question the successor has to ask is a gap; fix the document and repeat the step. Keep a dated record of both exercises, the access list with its owners, and the runbooks. That record is also what you show the auditor when they ask how you manage the risk of one person holding a critical system.

Who owns the app after the handover, and how do you cover the gap?

Name two owners: a business owner inside the organisation who is accountable for the app and its risks, and a technical maintainer who does the work. The technical maintainer can be an internal hire, but hiring usually takes longer than a notice period, so plan for cover in between. Short-term senior cover means an experienced developer or consultant who overlaps with the leaver, runs the verification exercises and holds the runbooks until the permanent owner is in place.

Solzet provides that cover remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of delivery. For Power Apps, Power Automate, Power Pages and Dataverse, that is our Power Platform developer service. For custom-built CRMs and business apps on React, Node.js, PostgreSQL or .NET, it is the team behind our custom CRM development. If the app is written in something else, we will say so on the first call. Where the app is a Dynamics 365 estate that nobody left can explain, our project rescue and takeover service is the starting point.

Do not decide whether to rebuild the app during the handover. Stabilise ownership first; the platform question can be answered properly once someone other than the leaver understands the system.

What should you do this week?

1. List every account the app depends on and move each to organisation ownership with two administrators.
2. Get all source, scripts and configuration names into the organisation's repository and vault.
3. Identify the three most frequent failures from tickets and logs, and start their runbook pages plus the restore page.
4. Draw the one-page dependency and integration map.
5. Write the manual payment fallback and book a rehearsal with finance.
6. Schedule the deployment and recovery exercises before the leaver's last week.
7. Name the business owner and arrange senior cover for the gap.