Franchise Software Migration: What Actually Has to Move

Franchise software migration is smaller than the fear around it. Four things have to move — current documents, open work, the people-and-permissions map, and the money connections. Almost everything else is history, and history can stay where it is, read-only, for the price of one export.

I sell one of the destinations, so discount this accordingly — then test it on any vendor offering to move a decade of your records. Ask what they refuse to move.

Where the switching-cost number comes from

Nobody in this market has measured a migration. There is no published figure for how long one takes, and the ranges in circulation are vendor pages quoting each other. Why deployments run long, and whose interest their length serves, is the subject of franchise software implementation time, which I am not going to re-run here.

What is worth separating is the three costs bundled into the single word "switching".

• Calendar. Your operations lead's hours, for some number of weeks. Real, and the only one of the three a proposal ever prices.
• Risk. The cutover weekend, the thing that does not come across, the month two systems disagree about the same number. A sequencing problem more than a technical one.
• Franchisee patience. The underestimated one. Your operators are independent businesses already asked to learn a system once, and in most networks they are paying for it — a technology fee sits in the disclosure documents of 61.9% of franchisors, on IFA's published analysis. A second migration inside a few years spends a currency you cannot buy more of.

The last two are why brands stay on tools they describe, unprompted, as broken.

Franchise software migration: the four things that actually move

Everything on this list is current. That is the whole test.

1. The documents in force. Today's manual, today's forms, the training somebody completes next week. Not every superseded version — the live one, plus whatever your counsel says you must retain.
2. Open work. Commitments from the last round of visits, tasks in flight, a rollout half-finished across the network. Anything closed is history; anything open is your operating position, and losing it is what makes people hate a cutover for years.
3. The people-and-permissions map. Who owns which units, who manages them, who may see financials, what happens the day a unit transfers. The slow one, and slow because the old system's version is usually wrong — an argument for moving rather than against it.
4. The money connections. Point of sale and accounting, per location, a discipline of its own with its own failure modes: connecting register and ledger.

Sized honestly, that is a folder, a list, a spreadsheet needing decisions on a dozen edge cases, and one connector per location with a reconciliation month behind it. What it does not contain is a decade of records — and a proposal built around moving those is built around the most expensive and least valuable half of the job.

What you are allowed to leave behind

History is the bulk of the data and almost none of the value: closed audits from three years ago, chat threads from a season nobody remembers, every superseded edition of the manual.

The exceptions are real and narrow:

• Anything under a retention obligation — your counsel decides this, not your vendor.
• Evidence in a live dispute, or in a matter likely to become one.
• The royalty and fee ledger, which is money and has to reconcile.
• The substantiation behind any financial performance representation you publish.

For everything else the move is an archive rather than a migration: one export to flat files you can read without a licence, held where your finance team already holds things, plus read-only access to the outgoing system for a cycle if the contract allows. Ask both vendors for a real export file from a live tenant, and do it at signature rather than at the end, when you have nothing left to trade with.

The sentence to distrust is "we will bring your history across." It sounds like generosity. It is a services line, and it turns a project measured in weeks into one measured in quarters, for records that will be opened twice.

Where AI compresses the work, and where it does not

What compresses is reading. A migration's real cost was never moving bytes; it was a person opening four spreadsheets to work out which franchisee list is the true one, or reading a manual end to end to decide what becomes an article and what becomes a task. A model can propose that mapping in an afternoon, surface the disagreements between your lists instead of quietly picking one, and draft the new structure for a human to correct. Correcting a draft is a different job from producing one, and it is the job a small headquarters can finish.

It also compresses the month after cutover, when a migration is really judged. The pain then is rarely missing data; it is people who cannot find things — and a system that answers "where did the allergen procedure go?" in the asker's own words absorbs most of it.

What it does not do is decide. Which version is authoritative, who may see whose numbers, whether a standard still applies in a market that changed since it was written — none of that is retrieval, and a demo blurring the line deserves a slower look. Judge those claims as you would any other model feature, using the tests in evaluating franchise AI features.

The sequence that keeps franchisees on your side

Migrations rarely fail technically. They fail as announcements.

• Move headquarters first and live in it for a month before a franchisee sees anything. If it is not good enough for you, it is not ready for someone who does not work for you.
• Never ask an operator to carry something across. Every item you hand them is an item that does not arrive.
• Answer one question on day one: where do I go now when I need to know something? The rest can wait a fortnight.
• Say out loud that the old system stays readable for a while. Much of the resistance is fear that something they depend on is about to vanish.
• Give the reason in their terms. "Faster answers, one place, and nobody asks you for the same number twice" is a reason. "We are consolidating our stack" is a memo.

Then leave it alone for a quarter. The temptation after a clean cutover is to launch three initiatives at once because the system finally makes them possible, and that is how a good migration becomes a bad memory.

The switching cost keeping a brand on a tool it dislikes is almost never an estimate. It is a memory of the last implementation and a fair suspicion that the next will have the same shape. Neither is a measurement, and neither is a reason to spend three more years feeding a system nobody opens unless told to.

Inventory what you are actually replacing before you price the fear of moving: the stack you already run.