Before making an AI service central to daily work, test whether you could replace it. A useful result is another person taking a prepared package and rebuilding one business process in a different approved environment. Downloading an archive does not establish that the process can move with it.
Who this guide is for
Owners and operations managers of small businesses using AI for internal writing, reference material or administrative drafts. The subject is a planned supplier change prompted by price, changing needs or service terms. This is Nadali’s suggested method; adapt it to the process, its risks and your budget.
1. Define what needs to move
Start with the outcome: for example, “prepare a product description from an approved product record”. Specify inputs, required output fields, prohibited assumptions and who accepts the work. Moving an entire account may be excessive; moving only finished text may lose the method that produced it.
Bound the test: one process, permitted test data, an owner, available time and a spending limit. Name dependencies that will remain, such as the product spreadsheet or approval system. Otherwise, the test might merely show that the replacement works while still relying on the original service.
UK government guidance on technical lock-in recommends balancing service benefits against switching difficulty. It also describes practical reconstruction as a way to reassess switching-cost estimates. For a small business, this is a useful principle rather than a requirement to build a complex multi-cloud system.
2. Assemble a reconstruction package
List the necessary components. Record each component’s location, owner, retrieval method and known gaps:
- Sources: original documents and spreadsheets, their names and links to particular tasks. Check links into the old service separately: they may require continuing access
- Instructions: your prompts, templates, examples, style rules and conditions requiring clarification. Preserve variable names so a colleague knows what to insert
- Workflow: step order, source-selection rules, input-to-output field mappings, approval points and destination of the result
- Configuration: model settings available to you, search rules, length limits, output format and integration dependencies. Mark inaccessible internal mechanisms as unknown
- Test cases: fictional inputs, expected facts, unacceptable mistakes and a method for checking the output
Keep passwords, access keys and unnecessary customer data outside the package. For connections, record what needs reconfiguring through the usual authorised process. If something cannot be exported, document whether it can be reconstructed manually and the work involved.
3. Inspect the export and permissions
Ask the supplier what your plan actually provides: sources, attachments, your instructions, settings or conversation history alone. Check the method, timing, possible charges and access after the contract ends. Keep the response and current documentation links. An “Export” button is not a promise of complete portability.
Separately check permission to use materials in the destination. Being able to open a document in the original service does not settle licensing, contractual or transfer-permission questions. Exclude uncertain material until an authorised specialist has checked it. This guide does not establish legal rights to export or reuse content.
Inspect sample records and attachments. Have identifiers, Ukrainian characters, units, column names and relationships survived? The government CSV standard separates the tabular format from column types and content validation. Its metadata guidance explains how descriptions of structure support data exchange. The practical implication: include a field dictionary rather than relying on the filename extension.
4. Rebuild without the old system’s help
Give the package to a colleague who did not configure the original process. Have them reconstruct a limited version in an approved test environment using fictional or appropriately anonymised materials. Record every occasion requiring the original service or the person who configured it: each reveals a specific gap in the package.
Agree acceptance criteria first. Check required facts, traceability to sources, correct structure and absence of invented features. Include missing information and conflicting materials. Identical wording is unnecessary; the relevant outcome is usable work that satisfies the agreed rules.
NIST AI RMF Playbook, MANAGE 3.1 recommends documentation and testing of third-party AI components. This portability exercise is an editorial application of that approach, not NIST certification.
5. Hypothetical example: product descriptions
Imagine a small workshop preparing draft descriptions from product records. Its team transfers ten fictional records. This is an illustrative set, not a universal recommendation for test size.
The files open, but the “size” field has lost its unit and the rule against unsupported product claims exists only in the original assistant’s settings. The archive download succeeded; process reconstruction has failed. The team adds the field definition and complete instruction template, repeats the tasks and checks every mandatory condition. It records the correction time as part of the future switching cost.
6. Budget for switching and human work
Include extraction, format cleaning, reconfiguration, checking, training and any overlapping subscriptions. During migration, specify which drafts staff can prepare without AI, from which materials and at what volume. Test that capacity on a sample task. A manual bridge has a real capacity and cost.
Actions for this week
- Choose one process and a test owner
- List its components and obtain a sample export
- Separate available, reconstructable and unavailable elements
- Ask a colleague to rebuild it and record gaps
- Decide whether to expand usage, simplify dependencies or defer
Limitations and conclusion
A small test does not demonstrate migration of all data, peak workloads or future product versions. Proprietary models, hidden configuration and retrieval mechanisms may not be reproducible. NIST describes its Playbook as voluntary guidance.
The purpose is to know what you can take, what requires rebuilding and when a move is acceptable. Revisit the test before substantially expanding usage or changing the contract. Dependence can be a conscious choice when its cost and limits are understood.
