Practical AI operations guide

Plan an AI automation vendor exit before you need one

A folder of exported files does not necessarily let another supplier operate your automation. The running service may depend on account ownership, business rules, scheduled work, credentials, data mappings and knowledge held by the original builder. An exit plan identifies what the business needs to continue operating and tests whether the handover material is sufficient.

This is an operational planning guide, not legal advice about ownership or contract rights. Confirm those rights through your own agreements and advisers. The practical task is to inventory dependencies, establish access, account for work in progress and rehearse a replacement using the information you can actually obtain.

Review my automation handover (03) 9003 0111

Vendor transition workflow: inventory dependencies, export and inspect records, rehearse the replacement, and reconcile the cutover. Select the diagram to view it full size.

What the next operator must be able to do

Access

Reach the right accounts

Business-controlled access should work without the departing operator.

Understand

Reconstruct the rules

Record mappings, decisions, exceptions and operating assumptions.

Operate

Complete a controlled case

Use the handover material to run a known scenario.

Recover

Account for pending work

Keep source references and uncertain outcomes through the transition.

Separate possession of files from operational independence

A useful exit plan is tested against the work the business needs to continue doing.

The account owner can matter more than the export

A complete workflow file is of limited use if it depends on a supplier's personal account or an inaccessible service subscription. Inventory each account, its administrative owner, billing responsibility and recovery method. Confirm the business can exercise the access it expects through a safe read-only check. Do not assume that receiving an invoice for a service means the business owns every connected account or has the right to transfer its configuration.

Business rules are often outside the workflow file

A workflow may contain field mappings while important decisions live in a spreadsheet, an email or the builder's memory. Examples include which job status triggers a message, which supplier names map to an account and how a rejected booking is handled. Export those rules in a readable form and identify who approved them. A replacement operator needs to understand why the process behaves as it does, not just reproduce a collection of unfamiliar nodes.

Historical and pending records serve different purposes

Historical logs help reconstruct past events. Pending work determines what must happen next. Keep separate inventories of queued tasks, scheduled messages, unresolved exceptions and outcomes that remain unknown. Include the source references that connect them to destination records. A transition can look technically successful while losing tomorrow's appointments or replaying yesterday's completed jobs, simply because the handover focused on configuration rather than operational state.

A rehearsal reveals the missing pieces

Ask an authorised replacement operator to complete a controlled scenario using the handover material. Record every question they cannot answer and every access dependency they cannot satisfy. This is a more useful test than asking the original supplier whether the export is complete. The rehearsal should include an exception and a recovery case, because routine success often hides the undocumented steps that make a service maintainable.

Build an exit package around continuity

Treat the package as a maintained operating asset, with access and completeness checked before a supplier change becomes urgent.

Inventory

Inventory the service boundary

List the entry channels, connected systems, hosting, storage, notification paths, scheduled jobs and administrative accounts. Record which party controls each dependency and which items are shared with other clients or services. Include the business contact who can make a continuity decision. The inventory should distinguish what is known from what is assumed, especially where a supplier operates infrastructure that your team cannot directly inspect.

Access

Confirm access and export options

Check the current account roles and the available export mechanism for each source. Record the format, included fields, excluded material and any access or licensing conditions that require separate confirmation. Use read-only checks before changing administration. Keep credential transfer out of ordinary documents and email attachments. Where an export is unavailable, document the limitation and assess whether a different continuity method is needed.

Rules

Capture rules and configuration

Collect the current workflow definitions, field mappings, approved prompts, source documents, exception rules and operating instructions. Include version identifiers and dependencies so a replacement can tell which items belong together. Explain environment-specific settings without embedding secrets. Record manual steps that remain part of the service. An export that omits the operator's daily reconciliation procedure can be incomplete even if every software file is present.

Data

Export records with a usable index

Create an authorised sample export and inspect it. Confirm that identifiers, timestamps, relationships, attachments and status meanings survive in a form the next operator can use. Record counts and checksums where helpful, but also open representative records and compare them with the source. A matching file count does not prove that relationships or document content remain intact. Protect the exported data according to the business's access requirements.

Rehearse

Rehearse a replacement and exception

Use a controlled environment or a tightly bounded test to reconstruct an ordinary case, an exception and an uncertain outcome. Give the replacement operator the package rather than continuous hints from the original builder. Record missing information and update the package. Where the replacement platform behaves differently, make the resulting business decision explicit instead of silently changing rules to fit the new tool.

Cutover

Plan the cutover and reconciliation

Agree the final capture point, which service may write during transition, how new work is queued and who approves release. Inventory pending and unknown items before enabling the replacement. Reconcile destination state after the first controlled release and retain a recovery option that is actually available. Close supplier access through the approved process only after continuity and retention decisions are complete, not as an unexamined first step.

What to request for each part of the service

Task	Traditional	A useful handover deliverable	Notes
Workflow definitions	A screenshot of the automation	Current export plus readable rule notes	Screenshots help explain the flow but may not preserve configuration or permit a rebuild. Keep the version and dependencies clear. Test whether an authorised replacement can reconstruct the agreed behaviour from the package.
Source documents	A link to the supplier's drive	Authorised copies with ownership and version information	Confirm that the business can access the documents after supplier access changes. Preserve enough metadata to distinguish current approved policies from older drafts, and avoid collecting unrelated customer information just to make the archive larger.
Credentials and accounts	Passwords pasted into a handover email	Business-controlled accounts and a secure access transition	The operational objective is durable authorised access. Credential handling should use the business's approved secure process. Record the account and owner in the package, while keeping secret values outside the ordinary runbook.
Historical records	One large CSV	Documented fields, relationships and sample checks	Inspect how identifiers, time zones, statuses and attachments are represented. A replacement needs to interpret the data, not merely open the file. Compare representative rows with source records and record any omitted fields.
Pending tasks	The latest activity log	A reconciled inventory of outstanding obligations	Separate queued, scheduled, running, completed and unknown outcomes. Include the destination reference where available. This prevents the replacement from assuming every task without a local success message needs to run again.
Exception handling	Contact the old developer if stuck	An operator procedure with decision owners	Document the common reasons work is held, the evidence needed to resolve it and who has authority to act. Test an exception using the package so undocumented judgment calls surface before the supplier leaves.
Monitoring and alerts	A list of dashboard URLs	Checks, recipients, thresholds and response instructions	Confirm who receives alerts and what each signal actually measures. A dashboard login does not explain which failures need action. Include a test that proves the notification route reaches the intended internal operator.
Commercial dependencies	A monthly total	An account and service responsibility inventory	Separate hosting, platform subscriptions, usage charges and support responsibilities. Confirm current terms through the relevant agreement or provider. Avoid assuming the replacement can inherit a supplier discount, licence or shared service arrangement.

Common gaps in a supplier transition

A backup that has never been opened

An archive can be present but incomplete, encrypted without accessible recovery material or missing attachments. Test restoration of a representative sample and inspect the resulting records. Record both technical integrity and usable content. A checksum proves that two copies match; it does not prove the original export contains everything needed to run the service.

Both suppliers writing during the overlap

An overlap period can help observation, but uncontrolled dual writing can create duplicate messages or records. Assign one writer for each consequential action and define how the other environment is isolated. If comparison runs are used, keep them from contacting customers or changing operational data. Reconcile the first replacement outputs before expanding its authority.

An export that loses relationships

Flattened data can separate a task from its attachments or remove the link between a source request and a destination record. Check relationships with concrete examples, including revisions and exceptions. Document the join keys and status meanings. If the new system uses different identifiers, preserve a mapping rather than relying on names that may be duplicated or changed.

Stopping access before the final capture

Removing the departing supplier too early can leave the business unable to obtain the final state or explain a discrepancy. Leaving access indefinitely creates a different problem. Plan the sequence with the authorised account owner, including a final capture, verification and deliberate access closure. The appropriate sequence depends on the circumstances and should be agreed rather than improvised.

Treating contract assumptions as established facts

Do not assume ownership of source code, transfer rights or export entitlements merely because they would be convenient. Record the operational requirement and confirm the applicable agreement with the appropriate adviser. Keep unresolved rights separate from technical feasibility. A replacement plan may be technically possible while still requiring a commercial or legal decision before work can proceed.

Rebuilding undocumented behaviour without review

A new supplier may recreate an old workaround that nobody still wants, or remove one that supports an important exception. Ask the business owner to distinguish required rules from historical accidents. Use examples to verify the decision. A transition is an opportunity to make behaviour explicit, but it should not silently become a broad redesign during a continuity-critical cutover.

Worked example: transferring a service-request workflow

Consider a fictional repair company moving a service-request workflow to another operator. The current service reads approved enquiries, creates jobs and sends an internal summary. The first handover package contains the workflow export and a customer CSV. It looks substantial, but the replacement operator cannot tell which enquiries have already become jobs or which held requests need a manager's decision.

The continuity owner adds a pending-work register with stable source references, destination job identifiers and explicit states. Completed requests are separated from requests that failed before submission and requests with unknown outcomes after a timeout. The package also includes the rule that a particular service type requires manual approval. That rule previously lived in an email and was not visible in the workflow export.

During the rehearsal, the replacement operator processes a synthetic approved request and finds the expected job. They then receive a request of the manually approved service type and hold it with the correct reason. Finally, they inspect an unknown-outcome case and find that the original system already created a job. The replacement links to that result instead of submitting another job. These checks expose why a CSV alone was not a complete operational handover.

The cutover plan assigns job creation to only one environment at a time. New enquiries are held in a visible intake queue during the final capture. The owner verifies the final pending register, authorises a controlled release and inspects the first resulting jobs and internal summaries. A recovery decision remains available if the replacement cannot handle the agreed sample correctly.

After reconciliation, the account owner completes the approved access changes. The business retains the final export, mapping notes, rehearsal evidence and the explanation of unresolved items. The continuity owner records which accounts were checked, which sample records were restored and which operator performed the rehearsal. They also identify any dependency that could not be independently inspected. This makes the acceptance decision reviewable: another person can distinguish an exported file from a tested operating capability and can see which remaining questions still need a supplier or business decision. The package does not assert that all possible historical cases were tested. It states which behaviours were demonstrated and which dependencies remain, so the next review begins with an honest operating record.

How Yes AI can help prepare a handover

Review a defined continuity boundary

We can inspect the accessible parts of a selected automation and identify the accounts, rules and records needed to operate it. The review distinguishes verified material from missing information. It does not claim visibility into a supplier's private infrastructure or rights that the business has not established.

Create an operator-oriented package

We can help organise exports, mappings and instructions around the actions the next operator must perform. The package should make ordinary work, exceptions and recovery understandable. Any credential transition stays within your approved secure process, with account ownership and access responsibilities documented separately.

Run a controlled replacement rehearsal

We can scope a test using approved sample records and the available handover material. The result is a list of demonstrated behaviours and gaps that need resolution. A successful sample is useful evidence, but it does not prove that every historical record or untested scenario will transfer correctly.

Recommend staying with the current arrangement

A supplier change may not be justified if a clearer handover, better access arrangements or a documented exception process resolves the problem. We can help separate continuity needs from a desire to rebuild. The appropriate next step may be improving the existing service rather than replacing it.

Prepare the package while the service is still working

Resolve missing information before the transition deadline makes every question urgent.

Name the continuity owner and boundary

Choose the process that must continue and the person who can make transition decisions. Record the current supplier, internal operator and replacement contact if one exists. Agree which parts are being handed over and which remain outside the review.

Verify accounts and sample exports

Use authorised read-only access to check account ownership and available exports. Open representative records, including attachments and relationships. Record what cannot be exported or inspected, and assign a decision rather than treating the gap as an implementation detail to solve later.

Document rules and pending work

Capture the business rules, current configuration and outstanding obligations. Give each pending item a stable reference and meaningful state. Include operator procedures and exception owners so the next person can distinguish a routine action from a decision requiring review.

Rehearse from the package alone

Ask an authorised operator to run an ordinary case, an exception and a recovery case using the package. Keep test actions isolated from customers. Record every missing instruction and update the material before repeating the affected part of the rehearsal.

Approve cutover and access closure

Agree the final capture, single-writer boundary, reconciliation and recovery decision. Verify the replacement's controlled outputs before widening access. Complete the approved access changes and retain the handover evidence in the business's own accessible location.

Turn this guide into your next steps

Use these steps to prepare your own review. Tick a step once you have recorded its evidence. Ticks are temporary and are not saved or sent to us.

Name the continuity owner and boundaryVerify accounts and sample exportsDocument rules and pending workRehearse from the package aloneApprove cutover and access closure

Bring one example of the process you want to improve. We can help define the scope, checks and next decision. Consultation options and any fee are shown before you book.

Review my automation handover

FAQ

Does paying for an automation mean we own its source code?

That depends on the applicable agreement and rights, which this guide does not determine. Record what the business needs for continuity and confirm the legal and commercial position with the appropriate adviser. Operational access, data possession and source-code ownership are separate questions. Avoid basing a transition on an assumption that has never been checked.

Is a workflow export enough to change suppliers?

It may be one useful part of the package, but the next operator also needs authorised access, dependencies, business rules and the state of pending work. Test whether a controlled case can be completed using the material. If the operator needs undocumented explanations or inaccessible accounts, record those gaps before relying on the export.

Should we ask for all historical data?

Define the operational, business and retention requirements first. An indiscriminate export can increase handling effort and expose information that the transition does not need. Specify relevant records, relationships, attachments and time periods, then verify completeness within that scope. Decisions about retention and access should follow the business's own requirements and advice.

How can we test an export without risking production?

Use an authorised sample in a controlled environment and keep consequential actions isolated. Compare representative exported records with their source, including relationships and attachments. Rehearse ordinary work and exceptions without contacting real customers. State any production differences that the test cannot cover rather than presenting the rehearsal as a complete migration guarantee.

What if the supplier uses shared infrastructure?

Identify which parts can be transferred and which require a replacement arrangement. Confirm the available export and access options through the supplier and relevant agreement. A shared service is not automatically unsuitable, but the continuity plan must account for its boundaries. Do not assume the business can take over an environment that also serves other customers.

When should the old supplier's access be removed?

Plan the sequence with the authorised account owner and the circumstances of the transition. The final capture, continuity checks and security requirements all matter. Record the decision and verify the completed access changes. Avoid both indefinite unnecessary access and premature removal that prevents the business from resolving an incomplete handover.

How do we keep the exit plan current?

Review it when accounts, workflows, providers or business rules change. Include export and handover checks in the normal operations review, and repeat a meaningful sample rehearsal when the dependency structure changes. A dated package that describes a retired system is useful history but not a current continuity plan.

Make the next handover a testable process

Bring the workflow, your current access arrangements and the material already available. We can help identify the gaps and scope a practical continuity review.