back to overview
For agency owners·8 min read

Migrating from manual booking to managed infrastructure: a 48-hour roadmap

Hour-by-hour plan for moving an existing visa agency off spreadsheets and staff-at-keyboards onto managed booking infrastructure — without missing a single client's deadline in the transition.

Why the migration feels risky (and isn't)

48 hrs
To first live corridor
New applications only — nothing in-flight touched
0
Clients at risk during move
Corridor-by-corridor, not big-bang
4 weeks
To full automation
Old process retires as in-flight bookings complete

Every agency owner who has been running manual booking operations for more than a year has the same quiet fear: the stack works. It's flaky, it burns out staff, it loses slots — but it's running, and customers are getting visas. Changing anything while clients are in-flight feels like open-heart surgery on a patient who is technically still breathing.

The fear is reasonable and also mostly wrong. Migration is not a big-bang cutover. It's a corridor-by-corridor hand-off that leaves existing in-flight applications exactly where they were, and only sends new applications through the new system. At the end of 48 hours your agency is running dual-mode; at the end of four weeks the old mode is retired naturally as in-flight bookings complete.

This guide assumes a typical mid-sized agency: 150–300 applications a month, 2–5 operations staff, two or three portals in play (typically VFS + one other), and zero engineering headcount. If that's you, you can run this plan without writing a line of code.

The 48-hour plan, hour by hour

H0–8
Account + pilot — 5 internal applications
Create the Pro account. Submit 5 internal applications — not live client work — using real applicant data so the credential vault encounters real-world edge cases. Assign one ops person to shadow. Watch applications run CREATED → AUTHENTICATING → CHECKING_AVAILABILITY. Handle at least one AUTH_OTP_REQUIRED so your team knows that flow before a real client sees it.
H8–24
Corridor selection + bulk data import
Pick your highest-pain corridor (usually UK→Schengen or India→UK). Export all active clients in that corridor from your existing tool — spreadsheet, CRM, half a Notion page. You need name, contact email, destination, visa type, preferred window, and portal credentials. Upload via Bookings → Bulk upload. The system validates each row before queuing anything.
H24–36
Go live + operator console training
Run a 1-hour team walk-through of the operator console. Show how CREDENTIALS_REQUIRED escalations look, how to respond, how to mark a booking for retry. Every ops person should log in and claim at least one test escalation before a live booking needs them.
H36–48
First corridor running unattended
Your team is on exception duty only. If nothing escalates, they have time for client intake, document pre-review, and upsell conversations. This is where ROI starts appearing on day two.
At hour 48 you have:
One corridor fully automated. Existing in-flight bookings still running manually, still on track. Ops team trained on the 5% of exceptions that need human judgement. Zero client-visible disruption.

Week 2–4: add corridors, retire manual

With one corridor live, adding more is mechanical. Week 2 is your second corridor. Week 3 is your third. Week 4 is whatever tail corridors remain. By the end of week 4, all new applications flow through Opaige regardless of destination, and the old manual process naturally retires as its last in-flight application completes.

The one unavoidable step: retiring the shared-password spreadsheet and the WhatsApp "slot alerts" group. These are the emotional artefacts of the old model, and keeping them around confuses the team. Delete them publicly, announce the deletion, do not re-create them.

What to measure — and what to stop measuring

Old (coping) metrics
New (operating) metrics
Portal monitoring
Hours spent on VFS per week
Success rate per corridor (%)
Responsiveness
Slot alert response time
Time-to-BOOKED (median hours)
Reliability
Number of missed slots
Escalations per 100 bookings
Unit economics
Labour hours per booking
Cost per booking (Opaige spend ÷ bookings)
Target
n/a — no baseline
< 2 escalations / 100, < 3 hrs TtB

Old metrics stop being useful immediately — they were coping metrics, things you measured because you couldn't solve the underlying problem. The new metrics are operating metrics: they tell you how the system performs, not how hard the team is working around its failures.

Measure weekly for the first month, monthly after. Then you run the business on real numbers instead of inbox anxiety.