Can you move a printed QR code to a different provider?

Only if the printed code points at a domain you control. A dynamic QR code encodes the redirect hostname, so a code printed as bit.ly/3xY2p resolves through that provider for as long as it is in circulation, whoever you pay next. A code printed on your own custom domain moves by repointing DNS, with no reprint. A static code cannot be changed by any provider at all.

We make one of the tools this article is about. getdynamicqr is ours, so read this as a biased source and check anything that decides your purchase. Everything below is either a property of QR codes themselves — which you can verify with any generator — or a statement about what getdynamicqr does, which you can check on the pricing page.

Why a printed code belongs to its redirect

This is the part that surprises people, and it is worth being precise about because every other decision follows from it.

A dynamic QR code does not contain your destination. It contains a short URL pointing at your provider’s server, and that server does the redirecting. The pattern of black and white squares on your menu encodes something like bit.ly/3xY2p or qrco.de/abc123 — and that hostname is not one you can redirect. It resolves through DNS to somebody else’s infrastructure, and they decide what it answers.

So “switching QR code providers” is not one job. It is three different jobs depending on what you printed, and only one of them is a migration.

Find out which case you are in, in thirty seconds

Take any printed copy of the code and scan it with your phone camera. Do not open the link — read the URL your phone previews first. That preview is the answer.

What the preview showsWhat you haveCan it move without reprinting?
The final destination, in fullA static codeNo — the URL is the pattern
A provider’s short domainDynamic, on their hostnameNo — you do not control that host
A subdomain the provider gave youDynamic, on their hostnameNo — it looks like yours, it is not
Your own domainDynamic, on your hostnameYes

Case 1: the code is static

The destination is encoded inside the pattern itself. No provider, present or future, can change where it goes — there is nothing to change, because no redirect was ever involved. Static vs dynamic QR codes works through the distinction properly.

The only route forward is a reprint, and the thing worth doing at the same time is making the replacement dynamic so this is the last time you are in this position.

Case 2: the code is dynamic, on the provider’s domain

This is the common case and the awkward one. The code works, it is re-pointable, and it is re-pointable by them. You have two honest options and neither is a migration.

Keep the old redirect alive. Stay on the old provider’s cheapest tier purely so the printed codes keep resolving, and put new work on the new provider. Cost it out rather than assuming: a few dollars a month against a print run is usually the cheaper side of the trade, and it is a cost that ends when the printed material is replaced on its own schedule.

Or replace the codes at the next print run you were doing anyway. Menus get reprinted, packaging gets redesigned, signage gets replaced. Folding the change into a run already budgeted turns a migration into a detail.

What you should not do is cancel the old account and hope. A dynamic code whose redirect stops being served is a dead code on live printed material, and the failure is silent — the pattern still scans perfectly and leads nowhere.

Case 3: the code is dynamic, on your own domain

This is the one case that moves cleanly, and it is the entire argument for using your own domain in the first place.

Your codes point at a hostname you control. You recreate the codes at the new provider with the same paths, repoint the DNS record, verify a sample, and every printed copy follows. Nothing is reprinted and nothing is reissued. Custom domain QR codes covers the setup.

The migration checklist

Four questions to ask before the next print run

Every one of these is answerable in writing, by any vendor, before you commit — and each one is a case above that you avoid entirely.

For the record, since this article is on our own site: getdynamicqr supports custom short links and custom domains, exports scan history as CSV, and does not cap dynamic codes on the Pro plan. The pricing page has the current figures.

Questions people ask

Can I move a QR code I already printed to a different provider?

Only if the printed code points at a domain you control. A dynamic QR code encodes the redirect hostname, so a code printed as bit.ly/3xY2p resolves through that provider for as long as it is in circulation, whoever you pay next. A code printed on your own custom domain moves by repointing DNS, with no reprint.

How do I tell whether my QR code is static or dynamic?

Scan it with your phone and read the URL in the preview before opening it. If the preview shows the final destination immediately, the code is static and its destination cannot be changed by anyone. If it shows a short URL on a provider domain or your own domain, the code is dynamic and its destination is a redirect somebody controls.

Will my printed QR codes stop working if I cancel my plan?

That depends entirely on the provider, and it is the single most important question to ask before printing anything. A dynamic code is a redirect somebody has to keep serving, so a cancelled account can mean a dead code on printed material. Ask the vendor in writing and keep the answer.

Does my scan history move with me?

No. Scan history belongs to the account that recorded it, and no provider imports another provider’s analytics. Export it as CSV before you close an old account, because closing it is when the data goes.

How long does switching take?

If your codes are on your own domain, minutes plus DNS propagation. If they are on the old provider’s domain, switching is not a migration at all — it is a reprint, scheduled whenever your next print run was already due.