Fix Gmail App Password Not Working During Migration

You generated an app password, pasted the 16 characters into your migration tool, and Gmail keeps returning AUTHENTICATIONFAILED Invalid credentials (Failure). Nothing about the password looks wrong. You can sign in to the Gmail web UI with the regular account password, the address is correct, the IMAP port is 993, and yet every connection attempt fails inside two seconds. This page walks through the four real reasons a Gmail app password rejects, and the order to check them in so you stop guessing.

Why a Gmail app password fails#

Four root causes account for almost every "Gmail app password not working" ticket. They look identical at the protocol layer but need different fixes.

2-Step Verification is not actually on#

This is the single most common cause. The App Passwords page will sometimes display and let you generate a code even when 2-Step Verification is in a pending state — for example, when you added a phone number but never confirmed the SMS. The code Google hands back looks correct (sixteen lowercase letters, four groups of four) but the LOGIN command fails because Google requires confirmed 2SV before app passwords are honoured at the IMAP layer.

The password has been revoked#

App passwords don't have a fixed lifetime, but Google revokes them silently in several conditions. Changing the account password kills all app passwords. Signing out of all sessions from the security page kills them. A suspicious-activity flag — for example, signing in from a new country — revokes them. The 16-character string is still in your password manager, but the server no longer accepts it.

Regular password used by mistake#

A surprisingly common ticket. The operator copied the user's normal Gmail password from the IT handover sheet, which Google's IMAP endpoint will reject for any account that has 2-Step Verification turned on. If you can sign in via the browser but the IMAP layer rejects the same credentials, you are almost certainly missing the app-password step.

Workspace admin policy blocks app passwords#

For Google Workspace tenants, the admin can disable app passwords for the whole organisation or for specific OUs in the Admin Console under Security > Less secure apps. When the policy is on, the App Passwords page returns "The setting you are looking for is not available for your account." If you see that message, you cannot generate one — you need to migrate using OAuth instead. Mailbox Taxi supports OAuth for Workspace accounts and you can read the OAuth 2 glossary entry for the underlying flow.

If you're staging a wider Gmail-to-Microsoft move, the auth choice you make here matters for the rest of the project. The pair guides for migrating Gmail to Outlook and migrating Gmail to Office 365 both call out app-password versus OAuth decisions at the start.

Fixing the app password — step by step#

1. Confirm 2-Step Verification is active

   Open myaccount.google.com/security while signed in as the source user. Find the 2-Step Verification card and check the status reads On with a green tick. If it shows pending, mid-setup, or off, complete enrolment with either a phone number or an authenticator app before going further. Workspace accounts may need an admin to enforce this at the OU level first.

2. Open the App Passwords page

   Go to myaccount.google.com/apppasswords. If the page loads and shows a Select app dropdown, you're good. If it shows "The setting you are looking for is not available for your account," stop. The admin has disabled app passwords — switch to OAuth instead.

3. Revoke any old codes for this device

   Scroll down on the App Passwords page and look for an existing entry named after your migration tool or laptop. Click the bin icon to revoke it. This removes any stale code that might be cached in a credentials store and prevents two simultaneous codes for the same device.

4. Generate a new 16-character password

   Choose Mail as the app and Other (Custom name) as the device. Label it Mailbox Taxi (or whatever your tool is) and click Generate. Google returns a yellow box with the 16-character code. Copy it without the spaces — the display breaks it into four groups for readability but IMAP expects the bare string.

5. Authenticate against imap.gmail.com:993

   In your migration tool, set host to imap.gmail.com, port to 993, encryption to SSL/TLS. Username is the full Gmail address (including the @gmail.com or custom Workspace domain). Password is the 16-character code with no spaces.

6. Run a single-mailbox test

   Before queuing the whole batch, push just this one mailbox through the migration tool and confirm the folder list loads. If it does, the credentials are valid. Only then add the rest of the accounts to the job.

Preventing this on the next migration#

Generate app passwords inside a 48-hour window of the cutover, not weeks ahead. The chance of a silent revocation grows with time, and a fresh code rules out half the failure modes above. Keep them in a password manager keyed to the email address so a teammate can find them when you're offline, and revoke every one of them after the cutover completes — leaving live app passwords sitting in a vault is an audit finding waiting to happen.

For migrations of more than about ten mailboxes, switch to OAuth where possible. App passwords don't scale: each one is a manual step in the source user's account, and a Workspace admin can't generate them centrally. OAuth lets you authorise once and migrate every mailbox in the tenant. Our app password glossary entry covers the trade-offs in more depth.

FAQ#

If you're still stuck after the steps above, the email migration troubleshooting hub catalogues the rest of the auth and throttling errors you're likely to hit on the same job.