Replacing a phone is routine until you reach the authenticator app. Contacts, photos and messages have their own migration paths, and most people have done those before. The six-digit codes that stand between you and a dozen accounts follow different rules, and the moment to discover that is not after the old handset has been wiped and handed on. If what you want is a messaging app on a second phone rather than a replacement for this one, linking a device is a separate decision — and one that neither moves authenticator entries nor removes the need for this migration.
TL;DR: There is no single authenticator-migration procedure. Google Authenticator can sync entries to your Google Account or move them by an on-device export, and deleting a synced entry removes it from every synced device. Microsoft Authenticator backs up and restores only within the same device type, and for work, school and passwordless entries it restores the account name while still requiring a fresh sign-in. Keep the old device working and signed in until you have confirmed both that the new device signs you in and that an independent recovery path exists.
Three mechanisms, not one procedure
The phrase “move my authenticator” covers several different things, and the differences are where people get stranded.
Some entries are synchronised, kept in step between your devices and an account rather than existing only on one handset. Some are exported and imported, moved deliberately from one device to another. Some are backed up and restored, which sounds equivalent to synchronising but carries restrictions that synchronising does not. And some entries do not move at all in any usable form — what arrives on the new phone is a name in a list, with the actual authentication still to be re-established.
Two vendors, two designs, and within each of them more than one case. Working out which case each of your entries is in is the whole task.
Google Authenticator: syncing and manual export
Google documents both paths on its page for getting verification codes with Google Authenticator.
Syncing. When you sign in to your Google Account within Google Authenticator on a new device, your codes are automatically synced to that device. This depends on those entries having been synced to that same account in the first place: synchronisation keeps copies on your devices in step with the account, so an entry that was never synced is not waiting there to be collected.
Manual transfer. Where entries are not synced, the old device exports them: from its menu, Transfer accounts, then Export accounts, selecting which ones to move, which produces QR codes. The new device uses Transfer accounts and Import accounts to scan them. This path needs the old device to be working and in your hands, which is one reason not to part with it early.
The consequence that catches people. Google states that if your codes are synced, deleting them removes them from all devices where they are synced. This matters because the natural instinct when finishing with an old phone is to tidy up by removing the accounts from the app before letting the device go. For synced entries that is not tidying up; it is deleting the entries everywhere, including from the phone you just set up. Retiring a device and deleting authentication entries are separate actions and should stay separate.
Microsoft Authenticator: backup, restore, and the wall between platforms
Microsoft’s design is a backup rather than a sync, and it has a restriction worth knowing before you choose your new phone.
Where the backup lives. Microsoft’s guidance on backing up your accounts describes Android backing up to a Microsoft personal account, and iOS using iCloud with iCloud Drive, iCloud Keychain and iCloud Backup enabled. Third-party entries that generate a one-time code every thirty seconds are included. Restoring therefore needs a backup that was actually made, to a store you can still reach, from a compatible platform — and reaching that store can itself require signing in, which is worth noticing if the second factor for that account is the phone you are replacing.
The same-device-type wall. Microsoft’s page on restoring account credentials is explicit that backup and restore work only on the same device type, and that accounts backed up on an iOS device cannot be restored on an Android device. If you are changing platform, this path does not carry your entries across, and you need to plan for re-enrolling rather than restoring.
A restored name is not a working method. This is the subtlety most worth absorbing. For work or school accounts, Microsoft states that only the account name is restored and you will need to sign in again. The same applies to personal accounts set up for passwordless sign-in. Entries that use a one-time code restore as working code generators; the others arrive as a list entry that looks reassuring and does not yet authenticate anything. Seeing the account name on the new phone is not confirmation that it works.
What each situation gives you
| Your entry | What arrives on the new phone | Still to do | Confirm first |
|---|---|---|---|
| Google, entries actually synced to the account you sign in to | The codes, on signing in to that same account | Nothing, if signing in produced them | That those entries were synced there, and that codes are accepted |
| Google, not synced | Nothing until you export from the old device | Export and import while the old phone still works | That the old device is available and functioning |
| Microsoft, same platform, one-time-code entry, with a reachable backup | A working code generator | Nothing, if codes are accepted | That the backup is accessible, and that a code is accepted rather than merely displayed |
| Microsoft, work or school, or passwordless | The account name only | A fresh sign-in to re-establish the method | That you can complete that sign-in before retiring the old phone |
| Microsoft, changing platform | Not restored across device types | Re-enrol with each service directly | Which services you will need to re-enrol with |
| Any service where the authenticator is the only factor | Whatever the rows above give | Establish a second route before you change anything | That the recovery path is one you can actually use — a published help page is not a factor you hold |
Confirm this before you retire the old device
The order matters more than the individual steps, and the principle is a single one: nothing irreversible happens to the old phone until the new phone is proven.
Keep the old device working and signed in. Not merely unerased — still functioning and still holding its sessions. It is your fallback for the entire process, and its value ends only once you have confirmed both that each method authenticates on the new device and that you hold an independent recovery path.
Sign in on the new device, for real. Not “the entry appeared in the list” but an actual authentication with each account that matters. This is the step that distinguishes a restored name from a working method, and it is the only way to tell them apart.
Confirm an independent recovery path for each account. Something you actually hold — recovery codes, a second factor you can still use, or a recovery route you have confirmed applies to you. A published help page is not a factor in your possession. If that second factor is an SMS code sent to a rented number, check what that number can still do before relying on it. Watch for the circular case: if the only way into the cloud account holding your backup is a code from the phone you are retiring, that path closes when the phone does. This is worth checking even when the migration appears to have gone perfectly.
Only then retire the old device, following the device maker’s own guidance for whatever you intend to do with it — keep it, pass it on, or return it. Whatever that route is, do not get there by deleting authentication entries one at a time from inside the app, for the reason given above. The old handset also holds other data and other accounts, so its disposal is a wider decision than this migration.
One thing that does not belong anywhere in this sequence: changing a SIM, porting a number or buying a new line does not move authenticator entries. Those secrets sit in the app and its backup, not on the SIM. If an account uses SMS as a second factor as well, that part does follow the number, and the two are easy to conflate — but they are separate systems with separate failure modes. That SMS side has its own conditions: a line has to be able to receive messages at all, which a data-only plan cannot, and a code that arrives still has to reach the field, which is a separate problem again.
Two situations worth walking through
Both are hypothetical, written to show the reasoning rather than to report a case.
The tidy-up that deleted the codes. Someone sets up a new phone, signs in to Google Authenticator, and sees their entries arrive. Satisfied, they pick up the old handset and delete the accounts from the app there before letting it go. Because those entries were synced, the deletion is not local to the old device. The reasoning error is treating the old app as a separate copy when synchronisation means it is a view of the same set. The safe sequence is to confirm that each method authenticates on the new phone and that an independent recovery path is in hand, and only then to handle the old handset through the vendor’s retirement guidance rather than by clearing entries from inside the authenticator app.
The account name that authenticated nothing. Someone else replaces an iPhone with another iPhone, restores Microsoft Authenticator from the iCloud backup, and sees their work account listed. They wipe the old phone. At the next sign-in prompt they find the entry present but not usable, because for work and school accounts the restore brings the name and still requires a fresh sign-in — one they can no longer complete easily, since the route they would have used ran through the device they have just erased. Nothing malfunctioned; the restore did exactly what it documents. What was missing was the step of actually signing in on the new phone while the old one still worked.
Limitations of this guide
This describes what Google and Microsoft publish about their own apps. It does not cover other authenticator apps, which use different backup and transfer designs, and it should not be generalised to them.
It does not offer reset, reinstall or clear-data steps, and does not tell you how to dispose of the old handset. Those interact with exactly the entries you are trying to preserve, and with everything else on that device, so the vendor’s own current documentation is the right place for them.
Account recovery is governed by each destination service, not by the authenticator app. If an account becomes unreachable, the route back runs through that service’s own recovery process and not through anything described here.
Export QR codes, setup keys and recovery codes are equivalent to the secrets themselves. They are not evidence to attach to a support request, not something to photograph for anyone, and not something to send to us or to anyone claiming to represent a service. If you are ever asked for one, that is reason to stop. The general form of that advice is in what to do about a verification code you did not request.
Our help answers cover the ordering side, and a support ticket is the route for anything specific to an order you placed with us.
FAQ
Will my authenticator codes move automatically to a new phone?
It depends on the app and on how each entry was set up. Google Authenticator entries synced to your Google Account arrive when you sign in on the new device; entries that are not synced need an export from the old phone. Microsoft Authenticator restores from a backup, but only on the same device type and, for some account types, only the account name. Treat “it will just come across” as something to verify rather than assume.
I am moving from iPhone to Android. Will Microsoft Authenticator restore?
Not by that path. Microsoft states that backup and restore work only on the same device type and that accounts backed up on iOS cannot be restored on Android. Plan on re-enrolling with each service directly, and do that while the old phone is still working.
Can I delete the accounts from my old phone once the new one is set up?
Not as a cleanup step, if the entries are synced. Google states that deleting synced codes removes them from every device they are synced to, which includes the phone you have just set up. Confirm the new device works and that you hold an independent recovery path, then retire the old handset by the device maker’s own guidance rather than by removing entries from inside the app.
The account shows up on my new phone. Does that mean it is working?
Not necessarily. For work, school and passwordless entries Microsoft restores the account name and still requires a fresh sign-in. The only way to tell a working method from a listed name is to sign in with it while you still have the old device as a fallback.
Does changing my SIM or phone number move my authenticator?
No. Authenticator entries live in the app and its backup, not on the SIM, so changing a number or a line does not move them. If an account also uses SMS as a second factor, that part does follow the number — which is why the two are easy to confuse even though they fail in different ways.
What if I have already wiped the old phone and the codes did not transfer?
Per-service recovery is not necessarily the first step. Check the vendor paths first: if Google Authenticator entries were synced to your Google Account and you can still sign in to it, signing in on the new device may bring them; if a Microsoft Authenticator backup exists, is reachable and was made on the same device type, restoring it may bring some entries back — subject to the same limits as above, since work, school and passwordless entries restore as a name and still need a fresh sign-in, and restoring does not complete every enrolment. Do that without tearing down sessions you still hold. Only where no applicable sync or backup helps, and no independent method you registered is available, does it become a matter of each service’s own recovery or administrator route, one account at a time.