Step-by-step how-tos for migration jobs

At the end you will have the ExchangeOnlineManagement module installed on your Windows or Mac admin computer, be connected to your tenant with Connect-ExchangeOnline, and know how to disconnect cleanly.

At the end the mailbox will be a shared mailbox that the right people can open, its sign-in will be blocked, and you will know whether you can remove its licence and how to turn it back into a user mailbox.

At the end you will have moved a group of mailboxes into Exchange Online with a migration batch, checked each user's progress and finalised (or cleaned up) the batch.

At the end you will have a migration endpoint in Exchange Online that holds the connection settings your migration batches use to reach the source mail system.

At the end you will have a PST copy of one or more mailboxes, made either centrally by an admin through Microsoft Purview eDiscovery or on a user's PC with Outlook for Windows.

At the end you will have uploaded PST files to Microsoft's storage with AzCopy and imported them into user mailboxes or archives with a Microsoft Purview import job.

At the end Outlook will open a new, clean profile connected to the user's new Exchange Online mailbox, and you will have checked that Autodiscover points to the right place.

At the end, mail sent to a user arrives in whichever mailbox they actually use during the migration: forwarded from the old system to Microsoft 365 before the MX change, or from Exchange Online back to the old system for people not yet moved, with automatic external forwarding allowed only where you need it.

At the end you will have downloaded the Hybrid Configuration Wizard (HCW), run it against your Exchange Server organisation and Exchange Online, and checked that hybrid is in place.

At the end you will have SPMT installed on a Windows machine, a file share copied into a SharePoint document library or OneDrive, and the reports that show what moved and what failed.

At the end you will have the Microsoft.Online.SharePoint.PowerShell module installed on a Windows PC and an authenticated Connect-SPOService session to your SharePoint admin URL, ready to run SPO cmdlets.

At the end you will have the MicrosoftTeams PowerShell module installed on your Windows or Mac admin computer, be signed in to your tenant with Connect-MicrosoftTeams, and know how to update the module and disconnect.

At the end every user in your tenant will be required to use multifactor authentication, through either security defaults or Microsoft's documented Conditional Access policies, with two emergency access accounts that cannot be locked out and a campaign nudging users to set up Microsoft Authenticator.

At the end you will have Microsoft Entra Connect Sync installed on a domain-joined Windows Server, syncing the OUs you chose from Active Directory to Microsoft Entra ID with the sign-in method you picked.

At the end both tenants will have each other added as organisations in cross-tenant access settings, with the inbound, outbound, trust and automatic redemption settings that cross-tenant synchronisation and tenant-to-tenant migrations rely on.

At the end the device's hardware hash will be registered in Windows Autopilot in your Intune tenant, ready for a deployment profile, either uploaded directly or imported from a CSV.

At the end your custom domain will be verified in Microsoft 365 and, if you choose, have the DNS records it needs for email and other services.

At the end every user who needs one will have a Microsoft 365 licence, assigned directly or through group membership, with a usage location set so the assignment succeeds.

At the end you will have created many Microsoft 365 user accounts at once, either through the admin center CSV import (up to 249 users per file) or with a Microsoft Graph PowerShell script.

At the end you will have the Microsoft Graph PowerShell SDK installed, be signed in with only the permission scopes you need, and know how to check and close the session.

At the end the domain will be gone from your tenant, with every user name, email address, group and app moved to another domain first, so it can be added to another tenant or service.

At the end, the mailboxes, SharePoint sites and OneDrive accounts in scope are covered by a retention policy or Litigation Hold, you have a list of every hold in place, and you know how to release them when the migration is finished.

At the end your extra domain is added to Google Workspace as a secondary domain or a user alias domain, verified with a TXT record, and ready for Gmail.

At the end, every user in your CSV file has a Google Workspace account in the right organisational unit with a starting password, and you have the upload report showing anything that failed.

At the end, the email, calendar and personal contacts from an Outlook profile or PST file on a Windows PC are imported into a Google Workspace account, with a log of anything that failed.

At the end your users' email (and, from Exchange Online, calendars and contacts) is copied into their Google Workspace accounts, with a report of anything that failed.

At the end you will have AzCopy on your machine, be authorised to your storage account, and have copied or synchronised a local folder to a blob container or an Azure file share, with a way to check and resume the job.

At the end you will have the az command working on your PC or Mac, be signed in to your Azure tenant and have the right subscription selected. If you cannot install software, use Azure Cloud Shell instead.

At the end you will have an Azure Migrate project, a registered appliance on your network and discovery running against vCenter Server or your physical servers, with the inventory flowing into the Azure portal.

At the end you will have the aws command installed, a working profile signed in through IAM Identity Center (or access keys), and proof of which account and role you are using. If you cannot install software, use AWS CloudShell.

At the end your Windows or Linux source server will have the AWS Replication Agent installed, appear on the Source servers page of AWS Transform MGN and be running its initial sync to your chosen AWS Region.

At the end you will have a powered-off copy of the VM as an OVF package (.ovf, .vmdk and .mf files) or a single .ova file on your workstation or file share, ready to import into another hypervisor or cloud.

At the end you will know whether each PC meets Microsoft's minimum requirements for Windows 11, which requirement blocks the ones that do not, and whether the blocker is a setting you can turn on (TPM or Secure Boot) or hardware that needs replacing.

At the end, new email for your domain is delivered to Microsoft 365 or Google Workspace instead of your old provider, and the old MX records are gone.

At the end your domain is delegated to a new DNS host that already holds a full copy of your records, so mail and web traffic carry on without a gap.

At the end you can tell whether a new MX, TXT, CNAME, A or NS value is live at your DNS host, at public resolvers, and as seen by Microsoft 365 or Google Workspace.

At the end you will have shortened how long resolvers cache your MX, A, CNAME or NS records, so the real cutover change reaches people quickly and can be rolled back quickly.

At the end, outgoing mail from your custom domain carries a DKIM signature that receiving servers can check against a record in your DNS.

At the end your domain publishes a DMARC policy, you receive aggregate reports, and you have a path to quarantine and then reject mail that fails authentication.

At the end your domain has exactly one SPF TXT record that authorises Microsoft 365 or Google Workspace (and any other services that send as your domain).

At the end your existing Microsoft 365 tenant, with its mailboxes and data, will be signed in to and managed through Microsoft directly, licensed with subscriptions you bought yourself, and GoDaddy will no longer hold admin roles over it.

At the end you have the IMAP server name, port, encryption setting and login details a migration tool needs to read mail from your old provider.

At the end you will have a complete copy of the site on your computer: every file in the WordPress folder including wp-config.php, plus an SQL export of the database, checked and stored in more than one place.

At the end you will be able to type wp on your server or computer and run WP-CLI commands such as wp db export and wp search-replace against a WordPress site.

At the end every reference to the old address in the WordPress database (links in posts, settings, widgets and serialized plugin data) will point at the new address, and the home and siteurl settings will match.

At the end each old URL will answer with a permanent 301 redirect to its new address, which Google treats as a signal that the new URL should be the one shown in search.

At the end you will have viewed and tested the site on the new server under its real domain name from your own computer, while everyone else still sees the old server, and then removed the override.

At the end you will have an SQL dump of the source database and that dump loaded into an empty database on the target server, with row counts checked.