Migrating Your Visa Agency's Data to a New System

Most agencies think of a system change as a technical project. It is not. The technical part — exporting rows, mapping columns, importing them somewhere else — is the small half. The hard half is deciding what your agency considers a client, a case, a document and a payment, and then holding to those definitions while several years of accumulated mess gets forced through them.

That is why migrations that are handed entirely to a developer or an assistant tend to stall. The person doing the export keeps hitting questions only the owner can answer. Is a family of four one case or four? Is a repeat applicant who used a different passport number the same client? Do we keep the enquiries that never paid? Every one of those is a business decision with an operational consequence.

The practical shape of a good migration is a short series of decisions made up front, a small amount of cleaning, one focused cutover, and a defined period where the old system is still readable but nobody is allowed to work in it. Agencies that follow that sequence finish in weeks. Agencies that skip the decisions spend months half-migrated, which is the worst state to be in.

Before you start, write down why you are moving. Faster intake, fewer missed documents, one place for payments, a client portal, whatever it is. That sentence is what you use to settle arguments later, when someone wants to recreate an old spreadsheet quirk in the new system purely because it existed.

Almost no visa agency keeps its data in one place, whatever the owner believes. Before you export anything, spend an afternoon listing every location where client information genuinely sits. The list is usually longer and more uncomfortable than expected.

A typical inventory looks like this: a master tracker spreadsheet with a tab per year; a second spreadsheet a senior consultant keeps for their own cases; a shared drive of scanned passports organised by folder name; an email inbox that holds the only copy of several embassy confirmations; a WhatsApp account on someone's phone with document photos clients sent directly; an accountant's ledger with the payment history; and a payment gateway dashboard that is the real source of truth for what money arrived.

For each location, write down who owns it, roughly how many records it holds, what date range it covers, and whether it contains anything you cannot get elsewhere. That last column is the important one. Data that exists in three places is easy. Data that exists only in one person's inbox or on one laptop is the risk — and it is also the reason to read up on backup and continuity alongside the migration.

Do this before you choose an import format. The inventory frequently changes the plan: agencies discover that the spreadsheet everyone argues about is actually 30% of their data, and the shared drive of documents is the other 70%. If you are still deciding between platforms at this stage, our guide to choosing the right CRM for a visa business covers what to test before you commit.

The instinct is to move everything. Resist it. A new system full of dead records is slower to search, harder to report on, and much harder for staff to trust — and trust is the whole point of the exercise.

Use three buckets. Move is everything live plus recent history: open applications, applications submitted and awaiting a decision, clients who transacted in roughly the last 12 to 24 months, active B2B partners, and your current price and visa-type configuration. Archive is older closed cases and anything you must retain for tax or regulatory reasons but do not expect to work on: keep these as a structured export file plus the matching document folder, stored securely and searchable, but outside the working system. Leave is everything with no ongoing purpose — enquiries that never replied, test rows, duplicate trackers, personal notes.

Be deliberate about retention rather than sentimental. Holding a scanned passport and bank statement for a client who used you once in 2019 is a liability, not an asset. A migration is one of the few natural moments to delete what you no longer have a reason to keep, and doing it here saves you doing it under pressure later. Our answer on where visa applicant data is stored covers the questions clients ask about this.

One more rule: your visa-type and pricing configuration is not data to migrate, it is a chance to rebuild. Do not copy a fee structure you already know is wrong. Rebuild it properly in the new system using your current thinking on the government fee versus service fee split, then map old orders onto it.

Duplicates are the single most damaging thing you can carry into a new system, because they do not look like an error. The record exists, the name is right, and everything seems fine — until half of a client's documents are attached to one record and their payment history to another.

Deduplicate in the export file, where a spreadsheet's own tools are on your side. Sort and compare on the fields that actually identify a person in visa work: passport number, date of birth plus surname, email address, and phone number in international format. None of these is reliable alone. Passport numbers change on renewal, family members share an email, and the same person appears as *Mohammed*, *Muhammad* and *M.* across three years of typing.

A workable pass is: normalise first (trim spaces, standardise phone formats to +country code, lowercase emails, fix obvious date formats), then flag exact duplicates automatically, then review near-duplicates by hand. For the manual review, decide in advance which record wins — usually the most recent one, with older detail merged in rather than discarded.

Give this job to someone who knows the clients. A junior assistant will merge two brothers with the same surname and similar dates of birth. A consultant who processed their applications will not. Budget real hours for it: for a few thousand rows this is a day or two of work, and it is the day that determines whether the new system is trusted or resented. Once clean, records land properly in applicant management with one client, one history, one document set.

Field mapping sounds mechanical and is not. The column called *Status* in your spreadsheet probably holds a mixture of workflow stages, payment states and personal shorthand. The new system will want those separated. Somebody has to decide which is which.

Build a simple mapping table with four columns: the old field, the new field, the transformation rule, and who decided. Then work through the awkward ones deliberately. *Status* usually splits into an application stage and a payment state. *Notes* often hides structured data — appointment dates, reference numbers, refusal reasons — that deserves its own field. *Fee* may or may not include the government fee, and if you do not resolve that before import, every revenue report you run afterwards will be wrong.

Stages are worth extra care. Write out the stage list you actually want in the new system — say intake, documents pending, document review, payment, submitted, appointment booked, decision, closed — and then map every old status value onto exactly one of them. Values that map onto nothing are the interesting cases; they usually reveal a step your process performs but has never named. Our guide to visa application workflow best practices is a useful reference when you are drawing that list.

Finally, dates. Standardise every date to ISO format before import and be explicit about what each one means: date of enquiry, date paid, date submitted, date of decision. Agencies routinely discover mid-migration that their single *Date* column means different things in different years, which is the kind of problem that is easy to fix in a spreadsheet and painful to fix in a live database.

Records migrate as rows. Documents do not, and they are usually the larger half of a visa agency's data. A shared drive with 40,000 scanned files organised by folder name is a real migration project in its own right.

Start by deciding what a document needs to be attached to in the new system: a client, a specific application, or a checklist item on that application. The third is the most useful and the most work, because it means each file needs a type — passport, photo, bank statement, invitation letter, insurance — not just a filename. If your folder structure already encodes the client name and the file names encode the type, a scripted import is realistic. If files are named *scan_0043.pdf*, it is not, and you should plan for a rules-based bulk attach at client level plus manual tidying on live cases only.

Be ruthless about scope. Attach documents properly for cases you will actually work on. For archived cases, keeping the original folder structure in secure storage is perfectly reasonable — you need to be able to find a 2021 file if asked, not to browse it daily.

Watch two practical traps. First, file size: years of phone-camera passport photos are often enormous, and it is worth compressing images during the move. Second, access: the moment documents land in the new system, permissions apply. Decide before import who should see what, because a shared drive where everyone sees everything migrates into a system where that may no longer be appropriate. Document management is where that structure pays off, and our answer on managing visa documents securely covers the client-facing side.

Cutover is the moment the new system becomes the place work happens. It should be short, planned and boring. The most common mistake is doing it gradually, which means for several weeks nobody knows where the truth is.

Pick your quietest day — for most agencies that is a weekend or a public holiday in your main source market, and never during peak season. Announce the freeze internally a week ahead: from a stated hour, no new intake, no status changes, no payments recorded in the old system. Then take the final export, run your cleaned mapping, import, and verify.

Verification is the part people rush. Do it in three passes. Counts: does the number of clients, open applications and recorded payments match the export? Spot checks: pick 20 records at random across different visa types and confirm every field looks right, including documents and payment totals. Live cases, all of them: every open application gets checked by hand by whoever owns it. There is no shortcut here, and it is also the fastest way to teach the team the new system.

Only after the live-case pass do you reopen intake. Then send one short message to your team stating plainly that from now on the new system is the record, and the old one is read-only. Clarity beats politeness on this point. If you are curious how long the setup half of this takes on a productized platform, we cover it in how long it takes to set up a visa CRM.

You will keep the old system around for a while, and that is sensible. The rule is that it is a library, not an office. Nobody creates, edits or updates anything in it. It exists so you can look up a 2023 refusal reason or an old invoice.

Set a switch-off date at cutover — 30 to 60 days is usually right — and put it in writing. Open-ended parallel running is how agencies end up maintaining two systems for a year, with staff quietly preferring the one they already know and the new system never becoming complete enough to trust.

Watch for the tell-tale signs of unofficial dual running: someone still keeping a personal tracker, a consultant emailing document requests instead of using the platform's request flow, payments recorded in a spreadsheet because it is faster. These are not discipline problems, they are usually signals that something in the new setup is genuinely slower than the old way. Find out which step, fix it, and the workaround disappears on its own.

When the switch-off date arrives, take one final full export of the old system, store it with your document archive, and revoke access. Do not simply cancel the subscription and hope — cancelled accounts get deleted. This is the same discipline that underpins backup and continuity generally: a copy you cannot restore from is not a copy.

The first month is where the migration is really finished or quietly abandoned. Watch three things.

Are staff opening the old system? If yes, ask what they are looking for. Usually it is one specific report or one field that did not come across cleanly, and it is a fixable gap rather than a general preference. Is intake going in fully? Partial records — a client created with no visa type, no fee, no documents — mean the intake flow is more work than the old one and someone is cutting corners. Do the numbers reconcile? Run last month's revenue and application counts in both systems. If they disagree, find out why now, while you still have both.

Expect a dip. Throughput almost always falls for two or three weeks while people learn where things are, then recovers past the old level. Tell the team to expect it, so the dip is not read as evidence the change was a mistake.

The agencies that get the most from a change of system treat it as a chance to redesign the process rather than to reproduce it. Visarunway built their operation around one platform and grew from zero to 2,000 monthly applications while cutting support enquiries by roughly 60% — not because the software was magic, but because a clean structure made automation and self-service possible.

One honest note on scope: VisaCRM is a productized service, built and branded for your agency, which owns it. It runs your intake, documents, payments and communication. It does not file government forms for you and it does not give legal advice — those remain your team's responsibility. If you want to talk through what a migration would look like for your data, get in touch.