A new phone is usually presented as a transfer problem: move your photos, messages, contacts and number, then wipe the old handset. Authentication apps complicate that tidy sequence. They may hold the rotating codes, approval prompts or sign-in credentials needed to enter the very accounts that help you recover from a mistake.
The useful question is not simply how to transfer an authenticator app to a new phone. It is whether every important account still has a working route in after the move.
That distinction matters because authenticator apps do not all migrate in the same way, and neither do the services protected by them. Google Authenticator can synchronise codes through a Google Account or move them through its transfer process. Microsoft Authenticator supports backup and restore for supported account entries, but work or school accounts need further sign-in and setup after restoration. Passkeys are a separate matter in Microsoft’s system.
This guide concerns time-based verification codes and app-based sign-in approvals. It does not cover moving a SIM, eSIM, phone number, password manager or mobile-carrier account. Nor is there one universal procedure for every authenticator app and every website. The safest approach is deliberately unglamorous: prepare, move or re-enrol, verify, and only then erase the old phone.
Treat the old phone as your fallback, not something to wipe first
The old phone is not clutter until you have proved the new one works. It is your fallback for a code that has not moved, an approval request that still arrives on the old device, or an account that demands fresh enrolment.
Microsoft makes the order explicit in its guidance for moving Microsoft Authenticator: complete the transfer before erasing, trading in or recycling the old phone. Its documentation also warns that a restored work or school account still needs additional sign-in and setup on the new device. Microsoft’s transfer guidance is a useful reminder that seeing an account name in an app is not necessarily the same as having a functioning sign-in method.
Keep the old handset charged, locked and in your possession while you migrate. There is no need to carry it indefinitely, but there is value in retaining it until your priority accounts have been tested. A phone that has been erased, traded in or handed to a recycler cannot provide an emergency approval prompt.
This is also why it is worth doing the move at a time when you can deal with an unexpected recovery process. Avoid beginning immediately before travel, a deadline at work or a period when access to banking, email or employer systems would be especially consequential.
Make an inventory before moving anything
“Authenticator” is a convenient label for several different jobs. An app may generate six-digit rotating codes, receive prompts asking you to approve a sign-in, support passwordless sign-in, or hold a passkey. Microsoft Authenticator, for example, supports multifactor authentication, verification codes, passwordless sign-in and passkeys, according to Microsoft’s documentation.
Do not assume that one transfer method covers all of those functions.
Before opening a migration screen, make a short account inventory. You do not need a catalogue of every site you have ever joined. Start with accounts that could lock you out of other accounts or cause a serious disruption:
- your primary email account;
- your Apple, Google or Microsoft account, where applicable;
- workplace or school accounts;
- financial, tax, government or health portals you use;
- password-manager accounts;
- shopping, social or cloud accounts that contain valuable records or could be used for account recovery.
For each one, note which authenticator app it uses and what it actually asks for at sign-in. Is it a changing code? A push approval? A passkey? An employer-managed setup? Is there another method already enrolled?
This need not become a security audit. The point is to expose dependencies before one of them becomes urgent. If your email account is protected by an authenticator app, it deserves attention before a streaming service. If a workplace account is managed by an organisation, do not assume its rules will match your personal accounts.
A simple written checklist, kept somewhere you can access during the move, is enough. Do not put recovery codes or passwords into that list unless you already have a secure place for them.
Separate passkeys from code entries
Passkeys are not merely another rotating-code entry. Microsoft states that passkeys are handled separately from Authenticator account backup. If a passkey existed only on the old phone, Microsoft’s guidance says you may need to add a new passkey for the new phone.
The practical implication is straightforward: include passkeys in your inventory as their own line items. Do not treat the appearance of a restored Authenticator account as proof that any associated passkey has arrived too.
Secure recovery routes while you can still sign in
A device move is the moment to check recovery options, not because every service offers the same ones, but because you can still inspect the account-security page while your existing authentication method works.
For important accounts, sign in on a browser or trusted device and look for available recovery controls. Depending on the service, these may include recovery codes, an alternate sign-in factor, a recovery email address, a phone number, or an existing signed-in device. Check that the contact details you rely on are current and that you still control them.
Recovery codes can be especially useful where offered. They are generally intended for the moment when your normal authentication method is unavailable. Their format and rules vary by service, so obtain and store them only through the relevant account’s own security settings. Keep them somewhere that will remain accessible if the phone is lost, reset or unavailable. A recovery code saved solely as a screenshot on the phone being replaced is not a reliable fallback.
Google’s guidance says that saving Google Authenticator codes in a Google Account can help protect against lockout when changing devices. But it also offers an option to use the app without an account. In that mode, the codes are stored on the device rather than being available through the Google Account. Google’s Authenticator support page explains both arrangements.
That is a useful example of the broader rule: convenience and independence can involve different risks. Cloud synchronisation may make a phone replacement easier; device-only storage may mean you need the old device for transfer. Neither arrangement eliminates the need to understand your recovery routes.
Choose the route your authenticator actually supports
It is tempting to install the same app on the new phone and expect the problem to solve itself. Sometimes it will. Sometimes it will only create a reassuring-looking but incomplete setup.
Use the documented route for the app you actually use, and distinguish app migration from service enrolment.
Google Authenticator: account sync or a transfer process
Google says that when you sign in to Google Authenticator with your Google Account on a new device, codes saved in that Google Account are automatically synchronised. That route is relevant only if your codes were saved to the account and you can still sign in to it.
Google also documents a transfer process for moving codes between devices. This is the more relevant route if you have not used account sync, or if you need to inspect exactly what is moving while both phones remain available. Follow the current steps in Google’s official instructions, rather than relying on an old screenshot or menu name: security apps change their interface over time.
If you chose to use Google Authenticator without an account, Google’s documentation says the codes are removed from Google Accounts and stored on the device. In practical terms, that makes keeping the old device available particularly important until the move has been verified.
Microsoft Authenticator: restore can be a starting point, not the finish
Microsoft describes backup and restore as a way to recover supported account entries and continue using secure sign-in methods. But its guidance contains an important limit for work or school accounts: after restore, the account name may be transferred so you can recognise it, yet you must sign in again to complete setup.
Do not interpret a familiar account label as a successful migration. Try the sign-in flow on the new phone. If the account belongs to an employer or educational institution, follow its enrolment process or contact the organisation’s support route if the new device cannot complete setup.
Microsoft also separates passkeys from Authenticator backup. Review passkey settings independently and add a replacement passkey where required. The details are set out in Microsoft’s transfer guidance.
For authenticator apps not covered here, do not infer that they offer cloud sync, QR export, backup or cross-device restore. Consult that app’s current support documentation before removing anything from the old phone.
Verify each important account on the new phone
Migration is complete only when the service on the other end accepts the new device’s authentication method. That is the part no app-transfer screen can certify for every bank, employer, retailer or social platform.
Work through the accounts on your inventory, beginning with your email account and other recovery-critical services. For each priority account:
- Start a fresh sign-in from a browser or device where doing so will not strand you.
- Use the new phone to generate the current code or approve the sign-in request.
- Confirm that the service accepts it and that you reach the account successfully.
- If prompted, complete any additional enrolment or confirmation steps.
- Check whether the account lists the old device or old authentication method separately, and remove it only after the replacement has worked.
Keep the test focused. You are not trying to prove every possible feature of every account. You are checking the sign-in route you will need if the old phone disappears tomorrow.
For work and school accounts, verification is especially important because Microsoft explicitly says that restored entries require further sign-in and setup. An employer may also impose policies that are not visible in the authenticator app itself.
If an account fails, stop rather than deleting or resetting more things. Use the still-working old phone, an existing recovery route, or the service’s documented account-recovery process. A failed test is inconvenient; it is also useful information while you still have your fallback.
Only then retire the old device
Once you have tested the accounts that matter, review the old phone one final time. Remove obsolete authentication methods where the individual service gives you that option, and make sure the new phone is the device you expect to use going forward.
Only after that should you follow the phone maker’s own documented procedure for erasing, trading in or recycling the old device. This guide cannot certify a migration remotely, and it does not replace device-specific wiping instructions. Its narrower point is that the old phone should remain protected and available until you have evidence that the new one can do the job.
A bounded decision card
You are ready to retire the old phone when:
- your primary email and recovery-critical accounts work with the new phone;
- any work or school account has completed its required setup;
- passkeys have been checked separately where relevant;
- you have reviewed available recovery options for important accounts; and
- you have not merely restored app entries, but completed successful sign-ins.
Keep the old phone for longer if:
- you have not tested priority accounts;
- an employer-managed account is awaiting enrolment or support;
- you cannot tell whether codes were synced, transferred or stored only on the old device; or
- a passkey or approval method still appears tied to the previous handset.
The disciplined sequence is less exciting than a one-tap phone transfer, but it preserves your options. In account security, a temporary duplicate is usually easier to manage than an avoidable lockout.
Questions worth asking before you wipe
Can I transfer Google Authenticator to a new phone without the old phone?
Possibly, but only in a specific situation documented by Google: codes saved to your Google Account can synchronise when you sign in to Google Authenticator on the new device. If the codes were instead stored only on the old phone, you may need the old device for Google’s transfer process. The relevant distinction is whether the codes were saved in the Google Account, not simply whether you remember your Google password.
Does Microsoft Authenticator backup restore my work or school account completely?
Not necessarily. Microsoft says work or school accounts require additional sign-in and setup after restore. The restored account name can help you identify the account, but you should not assume it is ready to approve sign-ins until you have completed the required setup and tested it.
Are passkeys transferred when I restore Microsoft Authenticator?
Microsoft says passkeys are handled separately from Authenticator account backup. Check each relevant passkey independently. If one was saved only on the old phone, add a new passkey for the new device as appropriate.
When is it safe to wipe my old phone after moving an authenticator app?
After you have successfully used the new phone for the accounts that matter, completed any work or school re-enrolment, and checked passkeys separately where relevant. Microsoft specifically advises completing the transfer before erasing, trading in or recycling the old phone.
Sources & methodology
This guide is based on current product documentation supplied for Google Authenticator and Microsoft Authenticator. It does not claim a universal process for all authenticator apps, services or device platforms. App menus, backup behaviour and organisation-managed sign-in policies can change, so check the linked documentation immediately before a phone replacement.
