Plan a prepaid API migration with a pilot cohort
Move a small, approved group of orders first. Match each one to the new supplier’s result and statement before you move more traffic. Keep a way to stop new orders while staff can still look up orders sent to either supplier.
| Gate | Evidence to proceed |
|---|---|
| Baseline | Current products, volumes and open orders recorded |
| Pilot | Approved cohort and owner identified |
| Reconciliation | Orders match supplier evidence |
| Expansion | Support and finance accept pilot results |
| Rollback | New submissions can be paused safely |
By Freepaid · Published
Plan the trial and capture a baseline
One department and 20 planned orders might be enough for a first trial. Set the actual size using your approval process, the supplier’s limits and the amount the business can risk.
Before switching, check who owns the current credentials, what products are mapped, which orders are still open and how finance last reconciled the account. Agree which supplier gets each order while both routes are open. Stop if a result remains unknown, the balances do not match or staff lose access they need. Have business, engineering and finance check the result before you expand.
Protect the migration boundary
Check existing credentials, mappings, scheduled jobs, open orders and reports before changing the route. Make sure a retry job cannot send the same request to both suppliers.
Limit the pilot to a team, product or order type. Match each pilot order to supplier records and ask support to rehearse what they would do if an order stayed pending. Check that staff know how to fall back before moving the next group.
To roll back, pause new orders on the new route and restore the approved previous route. Leave unresolved orders with the supplier that received them and keep their references available for lookup.
Record what moves with the pilot
Freeze the product mapping and export open references before cutover. Name who will move the orders, monitor the trial and tell support when to stop. Confirm that person can restore the old route. Log the exact time new orders move.
Try one approved department for one week if that gives you a useful sample. Match every submitted order to a status and the statement. If one result is still unknown, hold the next group until it is resolved or the person responsible formally accepts the risk.
An order sent just before cutover can complete after the switch. Keep the old lookup and reconciliation available until those cases close.
Reconcile both suppliers before expanding
Record both routes, the time traffic moved, the pilot group, open references and who approved the switch. Tell support how to tell which system received an order. After expansion, check the first close before revoking old access. Keep only the access needed for open cases and remove it as they close.