Vora
Choose a workflow whose boundaries you can name
An enquiry workflow is a better description than “the whole front desk.” Write down where a request enters, what ends the job and what staff do when it cannot finish.
For the workshop example, the boundary might be one website form and one service-request queue. Telephone bookings, payment collection and existing appointment reminders stay outside this first move. That makes the result easier to compare and gives the client a smaller change to absorb.
Choose a representative workflow, though. A test path that never touches the client's CRM will tell you little about migrating the work that does. Include the integration, permissions and failure handling that make the service worth paying for.
The same boundary helps when choosing a first-client deliverable. Write the service in terms of a finished client job before choosing the platform.
Agree a test window when someone from the client can inspect records. Name the person who can stop the migration if enquiries become inaccessible.
Inventory what the workflow depends on
Walk through one recent request using records you are authorized to inspect. Follow each destination, including the less visible ones such as a delayed reminder or an error notification.
Use a worksheet like this before copying anything:
| Dependency | Detail to record | Check in the destination |
|---|---|---|
| Incoming trigger | Form, webhook or schedule; responsible account | The intended source reaches the new workflow |
| Client identity | Tenant, workspace and account identifiers | Requests cannot cross into another client's records |
| Credentials | Owner, scopes and renewal method | The client-approved identity can perform the required action |
| Business data | Field mapping, required values and time zone | Staff see the expected values after saving |
| Agent configuration | Prompt, model settings and knowledge version | The same test input follows the agreed rules |
| Pending work | Queued requests, timers and approval waits | Each item has one continuing owner |
| External actions | CRM writes, messages and reservations | Repeats follow the agreed duplicate-handling rule |
| Support path | Alert recipient and fallback queue | A person receives enough detail to finish the job |
Treat an export as one part of this inventory. For example, n8n's export documentation says workflow JSON includes credential names and IDs. HTTP Request nodes imported from cURL can contain authentication headers. Inspect an export before sharing it, and reconnect credentials through the destination's supported process.
Keep secrets out of the migration worksheet. Store references to the approved credential records instead.
Compare the saved result with the client's expectations
Capture the current workflow's behavior before changing it. Use synthetic details and preserve the test inputs so both systems receive the same cases.
In the workshop example, send an enquiry for a brake inspection, then correct the registration number. Check which value reaches reception. The target workflow should preserve the final correction without creating a second service request.
“Same behavior” needs judgment. A known defect in the old workflow should not become an acceptance requirement. Record intentional changes separately so the client can approve them.
If the move is part of a paid AI pilot, agree which results support a buying decision before the test starts.
| Test case | Result to inspect | Evidence to retain |
|---|---|---|
| Complete request | Correct customer and service in the staff queue | Saved record and workflow version |
| Corrected detail | Final value replaces the earlier value | Input and reopened record |
| Missing required information | Agreed clarification or staff handoff | Conversation and queue entry |
| Repeated delivery | No unintended second business action | Request identity and resulting records |
| External timeout | Uncertain result stays visible for investigation | Attempt details and reconciliation decision |
| Unavailable connection | Work remains recoverable without a false promise | Held job and staff alert |
For voice workflows, include the checks in testing what happened after the call. Compare what the customer heard with what staff can open.
You can run a copy against test destinations before switching traffic. If you use live inputs for comparison, confirm authorization and prevent that copy from sending messages or making business changes. Two active copies can produce two real outcomes.
Give unfinished jobs one owner
The difficult request is often the one already running when you change the trigger.
List work waiting for a tool response, a retry, a human decision or a timer. Decide whether each item finishes on the old system, moves with its state intact, or closes through an agreed manual process. Moving a job should preserve its identity and completed steps.
Avoid giving both workers permission to finish the same item. A paused intake form does not establish that workers, timers or provider retries have stopped. Verify the controls in the platforms you use.
Preserve duplicate-handling records across the transition where the same business action can reach both systems. If the new system forgets that a request was already completed, an old delivery may look like new work. Amazon SQS standard queues, for example, can deliver a message again. Check your actual queue and webhook contracts rather than assuming a single delivery.
Use the webhook retry and idempotency guide to review request identities and the records that prevent a repeated business action.
A timeout deserves its own status. Find out whether the CRM accepted the write before resubmitting it. If the evidence remains unclear, assign a person to reconcile the request.
Write the cutover checklist before the test window
Keep this checklist beside the person changing the route. Record the observation or saved record that supports each check.
- [ ] The client has accepted the destination's business results and intentional changes.
- [ ] Required accounts, scopes and record destinations have been checked.
- [ ] The original configuration and routing details are recoverable.
- [ ] Every pending item has an owner and a finish, transfer or cancellation decision.
- [ ] The switch has a defined boundary, such as a recorded request sequence or routing change.
- [ ] One operator controls the switch and knows the stop conditions.
- [ ] A controlled request reaches the destination, creates the expected record and reaches staff.
- [ ] The old intake and its remaining workers behave exactly as the transition plan requires.
Keep the client's fallback and handoff method available during the switch. Staff need a usable fallback if the new integration fails while customers are still making requests.
Rollback also needs a record of what happened
Reverting a configuration does not remove a message already sent or a service request already created.
Define a rollback trigger in observable terms: requests landing in the wrong queue, missing required data, or an unresolved action that prevents staff from serving the customer. Agree who makes the decision.
When rolling back, stop new intake to the destination and account for its unfinished work. Reconcile external actions before the original system resumes those requests. Keep the same business identifiers so staff can distinguish an existing request from one still needing creation.
Rehearse this with synthetic work. Have someone other than the builder follow the instructions and locate the last completed action. If they cannot determine which system owns a job, the rollback procedure needs another pass.
Once the agreed observation period ends, use the offboarding checklist to retire old credentials, schedules and billable resources that the migration no longer needs.
After the cutover, review the next scheduled run as well as immediate requests. In the workshop example, open reception's queue when staff start their next shift. Check the last request handled by the old system, the first handled by the new one, and every item still marked uncertain.
A completed example
This is a hypothetical, filled-in plan for the workshop example. It covers one job only and does not describe migrating the whole stack.
| Element | Entry |
|---|---|
| Job | Website enquiry form to the service-request queue |
| Source and destination | Current assistant to the replacement assistant; same form, same queue |
| Owner | Client service manager approves results and can stop the switch; the agency operator performs it |
| Inputs | Three synthetic enquiries, including a corrected registration number |
| Expected record | One service request with the final registration number and a working link, visible to reception |
| Comparison | Same inputs on both systems; intentional differences listed for client approval |
| Cutover | Route the form to the new assistant at a recorded point; send one controlled request first |
| Rollback trigger | A request lands in the wrong queue or loses required data |
| Rollback action | Route the form back, then reconcile requests created in the meantime |
Telephone bookings, payments and reminders stay on the old system until they have their own plan. If a connection to a particular tool is involved, check that integration for your configuration before the test window; do not assume it exists.
Vora connects natively to selected tools; each integration lists the actions it supports. Check the Workflows page for the tool and action your migration needs before the test window.