Your AI supplier leaves on Friday. Who changes the rule on Monday?

Suppose your AI supplier finishes the handover on Friday. The documentation is in a shared folder, the source code is available and the final demonstration went well.

On Monday, finance changes an approval threshold.

Your operations manager knows the new rule. Your IT partner can open the code. Neither knows which setting controls the threshold, which tests would catch a mistake or how to put the old version back if the change goes wrong. The supplier receives another message.

You can test that handover gap before accepting the project.

Put someone else at the keyboard

Choose the person who would maintain the workflow after the engagement. That could be someone inside your company or another provider. You do not need to build an internal software department to have a credible alternative.

Give that person the materials the supplier intends to leave. Ask them to make one ordinary change in an isolated test environment, with no live orders or customer messages at risk. The original team can observe, but each intervention gets recorded.

An exercise that succeeds because the developer whispers the missing command has found a useful omission. Add the command to the instructions and repeat that part with the intended operator.

Agree the exercise before delivery, so everyone knows what the handover must enable.

Rehearse four actions

Start with a business rule your team expects to change. In the hypothetical approval workflow, that is the threshold above which finance must sign off.

1. Locate and change the approved rule. The operator should be able to identify the current value, who authorised it and where the replacement belongs.
2. Run representative tests. Include a case below the threshold, one at the boundary and one that must still go to finance. Decide the expected outcomes before running them.
3. Release the change into the test environment. Use the documented access and deployment steps. Check the behaviour there, rather than stopping at a successful build message.
4. Restore the previous version. Verify that the former behaviour returns and that any test records are reconciled. A backup file alone does not demonstrate recovery.

Keep a short record: action, person responsible, expected result, observed result and assistance required. The list of assistance becomes the remaining handover work.

Keep production access intact during the rehearsal. Monday's orders should not depend on whether the exercise succeeds.

Check what the next operator can actually obtain

The rehearsal will expose missing permissions quickly. It can also expose assets that never appeared in the delivery list: a test set on somebody's laptop, a scheduled job in a personal account or a connector whose configuration exists only in a chat.

For each dependency, record who controls it and how the next operator gets authorised access. Include service subscriptions and renewal dates. A copy of the code will not keep a paid external service running after its account closes.

Some components may remain licensed rather than owned. Have the agreement state the rights and transfer conditions plainly; ask your adviser to review the contractual wording. The operational test then checks what those arrangements let the next person do.

You can keep the supplier

You can renew support because the relationship works, with the option of transferring it later. Agree who handles incidents, which changes are covered and what happens if either party ends the arrangement. Repeat the rehearsal after a substantial change, because instructions for last year's release may no longer be enough.

At Solve IT, we scope implementation around the workflow and the people who will operate it. The transfer and support arrangements belong in that scope before the final demonstration.

Request a Strategy Session

Bring the rule your team would need to change first.