M365 Tenant to Tenant Migration
Hi Community, One of our customer currently migrating some OneDrive DATA from their old tenant to a new one. Customer wants to keep same domain names. So they must first remove them from the old tenant to create them in the new one. But they're afraid to loose the (OneDrive) DATA associated with the accounts when they will be moved to the initial ".ONMICROSOFT.COM" domain (which will happen after domain name removal). Questions: 1. What exactly happens with the accounts of OneDrive DATA once the old domain (wherein it was originally hosted) is removed ? 2. What is the best practice in this context to retrieve any associated DATA during/after migration? They want to check the priority steps knowing that they want to keep its domain name in the new tenant, which mean they'll have to detach the domain from tenant source to create it in target tenant 3. Should they first create a temporary domain where users will be migrated to, remove the domain name from tenant source to free it and create it in target tenant, then create the users ? or can they simply remove the domain name which will cause the existing users belonging to this domain to be automatically moved the initial .ONMICROSOFT.COM domain (with all the dependencies and OneDrive Data) ? Any pointers would be of great help! Many thanks in advance!
Need to Restore PST Files to Office 365 Mailboxes - What's the Best Approach
Hey everyone, I have a task coming up where I need to restore several PST files back into Office 365 mailboxes. Haven't done this before at this scale and honestly not sure where to begin. I've looked at Microsoft's native import service through Purview but I have a few concerns: Some of the PST files are quite large — not sure how well it handles that I need to restore only specific folders for some users, not the entire PST I'm worried about data consistency after the restore Would prefer something that doesn't require too many admin roles or complex setup For those who have done PST to Office 365 restores — what approach worked best for you? Any tools, tips, or things to watch out for that you wish you knew before starting?Migrate to Azure SQL Database, including Hyperscale, straight from Azure Arc (public preview)
The challenge Most organisations do not run in one place. Estates stretch across on-premises datacentres, hybrid deployments and the cloud, and every migration decision must balance application dependencies, operational requirements and a modernization roadmap that is already in motion. Mixed environments and legacy dependencies make that harder, and needing a different tool for assessment, migration, monitoring and management harder still. The result is more operational effort, inconsistency between teams, and modernization that moves slower than anyone wants. Azure Arc already solves the first half of that problem. It discovers and assesses SQL Server estates at scale, so you know which databases are ready to move. The second half has been the gap: once a database is identified as migration-ready, the path to Azure SQL Database runs outside Arc. You leave the experience you were working in, learn Azure Database Migration Service, configure a Self-hosted Integration Runtime, and juggle several tools to get one database across. That fragmentation costs time, and it is one of the reasons why assessments do not turn into migrations. What's new Azure Arc Database Migration now adds Azure SQL Database; including Hyperscale as a supported migration target, in public preview. You can migrate Arc enabled SQL Server databases to Azure SQL Database through a single, guided experience in the Azure portal. Behind that experience, the workflow integrates Azure Database Migration Service and streamlines Self-hosted Integration Runtime setup directly into the migration journey. You assess, configure, migrate, monitor and complete the migration without leaving Arc. This is a logical migration performed by DMS through the Self-hosted Integration Runtime, so there is no separate staging step for you to plan or maintain but it requires a planned downtime. Why Hyperscale For many teams, the database that most requires modernizing is also the largest one they run. Hyperscale is the Azure SQL Database service tier built for exactly that case: a fully managed platform designed to scale storage and compute independently as a workload grows, so a large SQL Server database can move to a managed service without being re-architected first. Making Hyperscale reachable from Arc matters because it removes a decision point from the middle of the journey. The databases Arc flags as migration-ready are often the ones whose size is used to rule out a managed destination; and now the assessment and the target sit in the same place. One portal, one operational model The principle has not changed: one portal for discovery, assessment and migration. The entire migration lifecycle is managed from a single tool in the Azure portal; assess readiness, select a target, configure settings, choose databases and tables to migrate, monitor progress and validate the results. Migrating to Azure SQL Database follows the same operational model already available for existing migration scenarios in Arc. The same migration dashboard, the same monitoring experience and the same guided workflow apply regardless of destination. That reduces the learning curve, keeps operational processes consistent, and lets your team choose the most appropriate Azure SQL platform for each database without changing migration methodology. How it works The flow starts where you already are, in the Database migration pane of your Arc-enabled SQL Server instance. Assess in Arc. Readiness assessments are generated automatically every weekend, and you can run one manually in a few minutes if you would rather not wait. SQL Server migration in Azure Arc is available by default for Arc-enabled SQL Server instances starting with SQL Server 2014 (12.x). Choose your target. Select Azure SQL Database, including the Hyperscale service tier, for the databases the assessment identified as ready. Set up DMS and SHIR, guided. The portal walks you through creating the Azure Database Migration Service resource and registering a Self-hosted Integration Runtime, inside the same workflow rather than as separate homework. Migrate. DMS performs a logical migration of your schema and data to the Azure SQL Database target through the integration runtime. Monitor and Completion. Track progress on the migration dashboard you already use, validate the results when the migration is completed. Microsoft Copilot is built into the Database migration pane to help you along the way. Why SHIR, and what it means for you The Self-hosted Integration Runtime secures bridge that it acts as the connectivity layer that enables Azure Database Migration Service to securely connect to the source SQL Server and the target Azure SQL Database for data movement. Azure DMS is a fully managed service for migrations to Azure data platforms and can be driven from the Azure portal, PowerShell or the Azure CLI — the runtime is simply how it gets to your source. In practice, setup is guided and one-time. You register the runtime once during the migration workflow, and subsequent migrations from the same environment reuse it. Nothing about how you operate your Arc-enabled instances changes. Learn more details in the technical documentation. Get started Trying the preview takes three things: an Arc-enabled SQL Server instance, a recent readiness assessment, and a target Azure SQL Database. In the Azure portal, open your Arc-enabled SQL Server instance, go to the Database migration pane, review the assessment results, and choose Azure SQL Database as your target. The portal takes it from there. Learn more: SQL Server migration in Azure Arc What is Azure Database Migration Service Create a Self-hosted Integration Runtime Step-by-step guidance for the new target We want your feedback For product feedback, feature requests, or migration pain points you'd like the team to track and act on, please share them through aka.ms/sqlfeedback under the Migration & Modernization category.
DNS connections
In 2021, I bought a domain and connected it to a Microsoft 365 account at the time. Over the years, I did not renew the domain and the 365 membership. Luckily last month, the domain was still available so I bought it back. Now, I can’t connect it to my new 365 account because it is still connected with the old one. I don’t have the username so I’m stuck at the moment
IMAP Migration from Google Workspace to Microsoft 365
Hello Team, Greetings!! We have recently been experiencing significant delays during IMAP migrations from Google Workspace to Microsoft 365 and would like to understand if there are any known issues or recent changes affecting IMAP migration performance. We are aware that Microsoft provides the native Google Workspace migration method, which would generally be preferable. However, in our migration scenarios, we have split routing/coexistence configured, with the domain configured as Internal Relay in Exchange Online. Because of this setup, we are currently unable to select/configure the required target delivery domain as expected during the native Google Workspace migration process. Could you please confirm: Whether there are any known issues, throttling, or performance degradation with IMAP migrations from Google Workspace to Microsoft 365 recently? Whether the Internal Relay/split-routing configuration can affect the native Google Workspace migration process or the availability of the target delivery domain option? Is there any recommended configuration or workaround that would allow us to use the native Google Workspace migration while maintaining split routing? Any guidance or recommended approach would be highly appreciated.
Tenant to Tenant Migration from Existing Hybrid Model
Our company was recently acquired, and the desire is to migrate our tenant into theirs. - we are in a Hybrid deployment (1 remaining OnPrem Exchange server** and using AzureAD Sync) - we are a relatively small shop (~51 accounts w/<400GB total in mailboxes, 200GB in OneDrive, very little in SharePoint) - we create users and mailboxes OnPrem and migrate them to O365 and manage them OnPrem **In preparation and testing for this, I have taken our OnPrem Exchange server out of the mailflow, pointed the MX records to O365, disabled the connectors, etc and mail flows perfectly fine. I also created a test user in our LocalAD and synced that account to O365 (didn't create a mailbox on the local Exchange server), assigned licensing and let it create an ExchangeOnline mailbox and that mail flows fine as well. - they are not hybrid - they are using Azure AD Sync. They create and manage users in their local AD and sync them to O365 (same as we do) - they do not have any OnPrem Exchange, so all of their users mailboxes are created in the cloud automatically as licenses are applied. The question is, what is the best approach? We've looked at some third party utilities for the migration that look good, but the concern with that method is what happens then to my local AD and AzureAD Sync; managing the existing users that were created, synced and then migrated; and my local users authenticating to it, etc? Are we going to be able to fully decommission the last Exchange server and not lose the ability to manage our folks. I need them to authenticate to our Local AD so do I then point AzureAD Sync to the domain in the new tenant? We talked about the possibility of simply creating the users manually in the other tenant, then exporting/importing their data to their new accounts (instead of migrating the account itself) to remove the need to maintain an OnPrem Exchange server if the users weren't created locally then migrated. How then does that affect them authenticating to our local AD since as I understand it, you cant sync from AzureAD back to a local AD. What about the possibility (same as what I wrote in BOLD above) of recreating all of the users in my local AD (with a different UPN), not creating mailboxes locally, syncing them to 0365, assigning licensing and letting the ExchangeOnline mailbox be created automatically (no mailbox migration like we are currently doing). Then we could import their PST to their new mailbox. Now, the users WOULD exist in our localAD and when we migrate that new batch of users to the new tenant, we could point AzureAD Sync to the new tenant and it should sync. AND since they never had a mailbox on our OnPrem Exchange server, there would be no need to maintain it. Appreciate any help on working through this!Large Dataverse Database Migration
Hello folks, Hoping someone has come across this challenge before - customer has a 1.5Tb+ prod database that needs to be reduced drastically. Is there a Support request route we can raise to create a DB copy into the customers Azure SQL? this would be the quickest route to get a copy before running bulk deletions. Long Term Retention wont be enough in this case either. Any thoughts welcome. TIATenant to Tentant Migrations - Which Third-Party Providers?
Hi there, We're going to be performing an O365 -> O365 migration for about 250 user accounts. I realise that we need to use third-party tools to do this and I've had experience using BitTitan.com for O365 migrations but the service is quite expensive and so I wondered if there were any other reasonably priced alternatives? We'd be looking at migrating Emails, Contacts, Calendar and personal OneDrives for all users. Thanks OllyTeams Delivers a Slack Migration Tool
Microsoft announced the availability of a Slack to Teams migration tool in the Microsoft 365 admin center. The new tool exists to assist the 79 million monthly active users of Slack who might want to move to Teams and don’t know how to get there. ISVs have been helping people move off Slack to Teams for years, so other migration options exist. https://office365itpros.com/2026/01/07/slack-to-teams-migration/
