Quest On Demand Migration: a tenant migration guide

How to prepare a Quest On Demand Migration project with verified matches

Quest On Demand Migration requires consistent preparation of the objects it links between source and destination. Before initiating transfers, we review which account each person will continue to use, what workloads are included, and what objects already exist in the arrival tenant. A display name match should not be used as the sole evidence that two objects represent the same identity.

In an acquisition, old accounts, duplicates, and people with prior access to both environments can coexist. The project manager must resolve these situations and approve the correspondences. Then we check how the chosen module and procedure uses them. This fix prevents an initial error from propagating to data and permissions across multiple services.

Preparation should also confirm requirements, licenses, and permissions for the features to be used. The platform groups together different components, but it is not advisable to assume that they all perform the same operations or have identical limitations. The design should specify what outcome is expected from each workload and what tasks are left out of the tool or need additional intervention.

How to use batches and reports to control the result

Batches must be organized so that the team can interpret the results and those responsible can validate the work. Grouping only by number of users can separate people and resources that depend on each other. These links and the department’s processes should be considered when defining the sequence, in addition to the volume of information to be processed.

During the pilot, preparation, execution, errors and retries allowed for the chosen workload are checked. The report is compared with functional tests and the necessary identifiers are retained to investigate differences. The acceptance must explain both the correct results and the omitted or pending elements, preventing a global percentage from hiding a case of high impact for the organization.

What is Quest On Demand Migration

Quest On Demand Migration is a Quest SaaS platform designed to assist in migration and consolidation projects for Microsoft environments. In Microsoft 365 it is mainly used in tenant-to-tenant scenarios, although the product family also includes Active Directory, Microsoft Entra ID and devices. Its proposal is especially useful in projects where there are several workloads. Instead of addressing email with one tool, SharePoint with another, and Teams with independent procedures, ODM allows you to manage a large part of the project from the On Demand ecosystem.

Quest currently documents capabilities for Exchange Online, OneDrive, SharePoint Online, Microsoft Teams, Microsoft 365 Groups, chats, Power BI, email domains, Active Directory and Microsoft Entra ID. That does not mean that there is exactly the same procedure or licensing for all of them. ODM is made up of different workspaces, services and capabilities, and some features require additional licenses. Official documentation: Quest – On Demand Migration.

What role does Quest play in the project?

The tool is most useful when understood as a execution platform for a previously designed migration strategy. For example, Quest can discover a Team and migrate it, but it cannot decide for the company whether that Team has been unused for three years and should be deleted. You can copy SharePoint documents, but not decide whether a legacy permissions model should be maintained in the new environment. It can help with mail, but the organization still has to decide when to release the corporate domain and change DNS records.

That separation between tool and architecture It is essential.

When it makes sense to use Quest On Demand Migration

Quest can be used for both relatively simple migrations and complex projects, but its value often increases when there are multiple workloads and many relationships between them.

Microsoft also continues to expand its own native cross-tenant migration capabilities. That is why the decision between Quest, Microsoft or a combination of both must be made after knowing the scenario, and not based solely on how these projects were resolved a few years ago. Microsoft Reference: Microsoft – Plan a Microsoft 365 tenant-to-tenant migration.

What Quest On Demand Migration can migrate

Talking about “migrating Microsoft 365” may be too generic. Each workload stores different information and has its own limitations.

“Supported” does not mean “everything stays exactly the same”

This nuance is especially important for Teams and SharePoint. Just because a tool supports a workload does not mean that all properties, applications, relationships, and user experiences can be 100% reproduced in the new tenant. Microsoft APIs, security models, and the Microsoft 365 architecture itself set limits. That is why Quest maintains specific sections of What We Migrate, Limitations, Considerations and Prerequisites for each workload.

In a migration proposal, it is advisable to describe the scope by object: for example, “Teams and standard channels”, “1:1 chats”, “associated files”, “Planner not included”, etc., instead of simply using the phrase “full Teams migration”.

Quest vs. native Microsoft tools

This comparison is much more relevant today than a few years ago. Microsoft already has native capabilities for Exchange Online, OneDrive, and SharePoint and is developing a Migration Orchestrator experience for coordinated moves. Quest continues to have advantages in certain projects, especially when the organization seeks a common console, discovery, mapping, remigrations, coexistence or multiworkload coverage.

There is no universal answer. In some projects the native method will be sufficient and more convenient. In others, Quest’s operational value will justify licensing it.

How to plan the architecture of a migration with Quest

An ODM migration should start on an architecture sheet, not on the button Create Project. The first thing is to decide which will be the definitive tenant, which users will move, which domain they will use, what data will be moved and for how long both environments should coexist. From there the order of the workloads is designed. The general principle is to first resolve the identity and correspondences between objects. The data workloads are then prepared and migrated. Finally, those changes that must necessarily be concentrated in the cutover are executed, such as the corporate domain and certain email or application configurations.

Assessment and inventory before setting up Quest

Quest can perform discovery of many objects, but that is not a substitute for a functional assessment. The tool can find a SharePoint site; The business must decide if that site is still necessary. A good assessment looks for three things: what exists, what depends on what and what is worth moving.

Use the project to clean up, not duplicate problems

A tenant consolidation is a good time to remove inactive Teams, abandoned SharePoint sites, old accounts, and permissions that should no longer exist. Migrating absolutely everything is usually easier to decide, but not necessarily better. It increases the volume, cost, execution time and the amount of information that will have to be governed later.

Quest On Demand Migration permissions and security

A migration platform needs access to a large amount of information. That’s why permissions should be part of the project’s security design and not simply treated as a consent screen that must be accepted. Quest maintains a Permissions Reference Guide in which it documents the permissions required per workload and has options to reduce the scope of certain accesses.

SharePoint and Sites.Selected. Quest currently documents the use of Sites.Selected for certain SharePoint scenarios. This model allows you to authorize the application only on specific sites, instead of granting indiscriminate access to all collections in the tenant. In projects where the tenant contains information that is not part of the migration, this approach can help better enforce the principle of least privilege.

Exchange and RBAC for Applications. Quest also documents support for RBAC for Applications on Exchange Online, which allows you to delimit the access scope of the application used to migrate mailboxes. It is a significant improvement compared to models where the application automatically has global access to all of Exchange Online. Microsoft Teams. Teams presents a more complex scenario because certain operations depend on Microsoft Graph and may require application permissions, delegated permissions, and temporary service accounts for certain tasks.

The project design should document which Quest applications are authorized, what permissions they receive, what service accounts are used, and what items should be retired or reviewed upon completion. Official documentation: Quest – On Demand Migration Permissions Reference Guide.

Discovery and mapping: the basis of a successful migration

One of the most important concepts of ODM is matching or mapping. The tool needs to know that ana@empresa-antigua.com in the origin tenant corresponds to ana@empresa.com in the destination tenant. The same logic affects groups and other objects. A mapping error can result in data associated with the wrong user, permissions that are not reconstructed correctly, or chats whose participants do not exist in the destination.

What should be checked before approving the mapping.

For large environments, it is advisable to review the result of automatic matching and use explicit mapping for exceptions.

Custom domains, DNS and coexistence

Quest can facilitate certain phases of coexistence, but the corporate domain is still subject to Microsoft 365 rules. A domain like empresa.com must be released from the source tenant before being fully incorporated into the target tenant. This forces you to find and change all existing references.

Domain Rewrite

Quest has a capability called Domain Rewrite, aimed at certain mail coexistence scenarios. The service can rewrite addresses to help users maintain a consistent email identity while they are split between two environments during the transition. Its deployment has implications for mail flow, connectors, SPF and DKIM, so it must be designed as part of the coexistence architecture and not activated in isolation.

Official documentation: Quest – Domain Rewrite Quick Start Guide. Free/busy information across tenants. Quest also offers coexistence capabilities for Exchange that can help maintain calendar visibility during a phased migration. This is especially useful when part of the company is already in the new tenant and another part remains at the origin for several weeks. Official reference: Quest – Exchange Online migration and coexistence.

Migrate Exchange Online with Quest

Exchange is often the workload that defines the perceived success of the migration. Users can tolerate a SharePoint link needing fixing, but any prolonged mail outage immediately creates a business problem. ODM allows you to work with Exchange Online mailboxes and coordinate the migration with other workloads such as OneDrive, SharePoint, and Teams.

What to analyze before starting

Not all mailboxes are the same. A user with 5 GB of email and no delegations is very different from a manager with an online file, assistants with Full Access and several SMTP addresses.

Premigration and final synchronization

One of the common advantages of using a specialized tool is being able to separate data movement from when the user changes tenants. An important part of the content can be migrated in advance and subsequently run additional tasks to bring the destination closer to the current state of the source before the cutover, always following the behavior documented by Quest for the loading and options used.

This helps reduce the amount of information that must be processed during the final window. The mail does not end up in the mailbox. During the cutover the following must also be resolved: MX, Autodiscover, SPF, DKIM, DMARC, aliases, mail routing, Outlook, mobile, SMTP applications and third-party security services. That’s why Exchange must have a specific runbook for the change window. Official reference: Quest – Exchange Online Migration.

Migrate OneDrive with Quest

OneDrive needs a different approach than Microsoft’s native cross-tenant mechanism. In Quest, The destination OneDrive must be provisioned before starting certain migration tasks. Current documentation recommends that it be provisioned at least 24 hours in advance. This detail is especially important if you are comparing Quest with Microsoft’s native mechanism, because in Microsoft’s Cross-tenant OneDrive Migration, practically the opposite happens: the destination site must not previously exist.

Sharing and migration order. Quest’s documentation also highlights an important consideration for shared permissions: when a user shares content from their OneDrive with another, the owner’s OneDrive should be migrated before the user receiving access. Otherwise, certain shared permissions may not be preserved as expected. That is why it is not always advisable to create waves only by department. Sharing relationships between users must also be analyzed.

What to validate next

Validation should combine volume and real interaction. It is not enough to compare the number of files.

Official documentation: Quest – On Demand Migration User Guide.

Migrate SharePoint Online with Quest

SharePoint is one of the workloads where prior assessment has the greatest impact. Quest’s own documentation clearly separates discovery, assessment, matching, and migration. This allows a site to be analyzed before deciding whether it should be moved. ODM may copy, among other elements, relevant metadata such as Created Date, Created By, Last Modified Date and Last Modified By, which can be important in documentary repositories where preserving historical context is necessary.

Not all sites should be treated the same

A project site with one library and twenty users can be migrated relatively easily. A departmental portal with single permissions, lists, Power Apps, automations, and external sharing needs specific testing.

Premigration Assessment. Quest has pre-migration reports that help identify problems before moving content. These reports are particularly useful for finding objects or configurations that require special treatment. It is a good idea to use them before the pilot and repeat them if important changes occur in SharePoint during the project.

Limited permissions with Sites.Selected

In projects where only a portion of SharePoint will be migrated, the ability to use Sites.Selected can significantly reduce the scope accessed by the migration application. This allows for a more restrictive configuration than granting unnecessary tenant-wide permissions. Official reference: Quest – SharePoint Migration.

Migrate Microsoft Teams with Quest

Quest has a specific workspace for Microsoft Teams Migration. The tool migrates Microsoft Teams and the associated Microsoft 365 Groups and also has specific functions for conversations and chats. Teams, however, remains one of the most delicate parts of any tenant-to-tenant because the information does not reside in a single service. Channel files depend on SharePoint. Files shared in chats may depend on OneDrive. Meetings depend on Exchange. Members are based on identities and groups. Applications like Planner, OneNote or third-party apps add more relationships.

Migration order

Quest currently recommends migrate chats after OneDrive, mailboxes, SharePoint, and Teams have been addressed, and after accounts are successfully paired. It makes sense: if participants aren’t already mapped or files referenced by a conversation don’t exist on the destination, chat migration is less likely to successfully preserve context.

Don’t promise “Complete Teams” without defining what it means. For a commercial or technical proposal it is much safer to specify each component. This prevents the client from understanding that absolutely all apps, tabs, conversations, meetings, and relationships in the original environment will appear identical after the change. Official reference: Quest – Microsoft Teams Migration.

Active Directory, Microsoft Entra ID and devices

One of the most interesting differences of the Quest platform compared to a tool focused exclusively on data is that it can extend the project towards identity and endpoints. On Demand Migration for Active Directory It is aimed at consolidating and migrating users, groups and devices between Active Directory, Microsoft Entra ID and hybrid environments. Quest documents scenarios such as:

Devices Entra joined and Intune

Quest has specific capabilities to move Windows 10 and Windows 11 devices between domain-joined, hybrid, and Entra-joined scenarios. In certain cases you can also change the Intune enrollment towards the target tenant. This can be especially interesting in a carve-out where not only the user’s data is moved, but also their laptop and profile. Endpoint migration, however, should have its own pilot. Windows Hello, certificates, Wi-Fi, VPN, apps, Intune, and Conditional Access can change the user experience.

Official reference: Quest – Active Directory and Entra ID Migration.

Power BI, Power Platform and applications

The most visible Microsoft 365 workloads are not necessarily the ones that will cause the biggest problem after migration. An enterprise application that uses the old tenant for authentication may stop a critical process even though all mailboxes have migrated successfully. Power BI. Quest includes Power BI within the platform’s capabilities, but a Power BI project must analyze elements such as workspaces, datasets, semantic models, gateways, credentials, connections, refreshes, and permissions.

It should not be treated as a simple copy of files. Power Platform. Power Apps and Power Automate can be connected to SharePoint, Outlook, Dataverse, SQL, Teams, and external applications. Therefore, even when related content is migrated, connections may require reauthentication or reconstruction. Microsoft also has specific procedures for certain Power Platform tenant-to-tenant migrations. Official Microsoft reference: Microsoft – Power Platform tenant-to-tenant migrations.

Enterprise Applications and App Registrations. The assessment should also record: Enterprise Applications, App Registrations, Service Principals, secrets, certificates, API permissions, SCIM, SSO, redirect URIs and automations based on Microsoft Graph. Many of these elements contain tenant-specific identifiers and will have to be reconfigured at the destination.

How to prepare a pilot with Quest that really works

A good pilot is not about selecting five random users. It should represent the complexity that will appear later in production. For example, if there are users with online files, Teams with private channels, large OneDrive, or assistants managing mailboxes, one of those cases should appear in the pilot.

The pilot must reproduce the production procedure: matching, migration, identity change when applicable, client configuration and final validation.

Pre-migration and wave migration

One of the reasons for using a specialized platform is to be able to decouple some of the data movement from the cutover day. When the workload allows it, a first migration can be carried out and later execute new tasks to capture changes before the outage. This allows the final window to focus primarily on: latest changes to data, domain, DNS, identity, mail flow, applications and user experience.

Collections and batches. In large projects it is advisable to create logical groups of users and resources. Waves can be organized by department, country, headquarters, or technical unit. The organization chart should not always be followed exclusively. If ten users continually share documents between their OneDrives, it may be convenient to move them together even if they belong to different departments.

How to prepare the cutover with Quest

The cutover is the moment where the tool and all the elements that Quest cannot decide automatically coincide: domain, DNS, applications, users and communication. It is advisable to prepare a runbook with time, person responsible, expected result and rollback criteria for each action.

Validation and subsequent support

One of the biggest mistakes is to consider a task in a state Completed as sufficient proof that the migration has completed successfully. The job demonstrates that the tool has completed an operation. It does not prove that the user can work. Validation should be done at two levels. Technical validation.

Functional validation. Then the user or owner of the service must come into play. The person responsible for Finance is the one who best knows if they can access the library they use for monthly closings. The assistant director knows if he can open the director’s calendar. The owner of an application knows if it is still receiving data. The combination of both validations is much more reliable than reviewing Quest statistics alone.

Hypercare. During the first days it is advisable to maintain reinforced support. Many incidents appear when the user tries to perform a task that they do not use every day. Hypercare also allows you to find patterns. If twenty users are experiencing the exact same problem, there is probably a common configuration that needs to be fixed, not twenty separate issues.

Common errors when using Quest On Demand Migration

Quest On Demand Migration FAQ

What do I need to prepare before using Quest On Demand Migration?

Workloads, objects, and identity mappings must be defined, and the requirements of the chosen procedure must be verified. The status of the destination, necessary licenses and permissions are also reviewed. The configuration must respond to the approved scope; a name match or default value is not a substitute for that review.

Do all Quest modules have the same scope?

It should not be assumed. Each workload and function needs to check its current requirements, capabilities and limitations. The project should indicate what result the user will achieve and what requires reconstruction or additional work. This review allows you to plan and validate without transferring the expectations of a single function demonstration to the entire environment.

How should migration batches be organised?

Identities, resources, and work dependencies are considered in addition to volume. Those responsible must be able to validate what is included in each phase and understand what temporarily remains at source. The pilot provides information to adjust the grouping and the schedule, avoiding separating components that need to function in coordination during the transition.

Is the Quest report enough to accept the migration?

The report provides technical evidence, but must be contrasted with the usability tests included in the scope. Errors, omitted elements and differences are reviewed, and access, data and processes are checked with representative accounts. The acceptance records these results and the approved exceptions, with those responsible for monitoring them.

Final Recommendations: Quest is Powerful, but Migration Still Needs Architecture

Quest On Demand Migration It is one of the most complete platforms to address Microsoft 365 tenant-to-tenant migrations. Its coverage of Exchange, OneDrive, SharePoint, Teams, identity, devices and coexistence allows you to address projects that go far beyond copying mailboxes. Its greatest value appears when there are many workloads and dependencies. Discovery, matching, batch tasks, premigration capabilities, reporting, and specific Teams, Active Directory, or Domain Rewrite modules can simplify projects that would otherwise require coordinating numerous independent tools and procedures.

But using Quest doesn’t eliminate the major challenges of a migration. The domain needs to continue to be planned, applications need to be reconfigured, permissions need to be validated, and users need to know what is changing. Additionally, the native capabilities of Microsoft 365 have evolved greatly. Today it is reasonable to compare Quest with Cross-tenant Mailbox Migration, OneDrive, SharePoint and Migration Orchestrator before choosing the final architecture.

Therefore, the correct order should always be: assessment, scope definition, identity and coexistence design, tool selection, pilot, premigration, waves, cutover, validation and hypercare. The tool is chosen as a consequence of that analysis, not the other way around.

Recommended official documentation

Quest On Demand Migration is a platform that is updated regularly. Before executing a project, it is advisable to consult the current documentation for the specific workload. Quest On Demand Migration.

• Quest – On Demand Migration
• Quest – On Demand Migration User Guide
• Quest – Permissions Reference Guide.
• Quest – On Demand Migration Technical Documentation

Exchange Online.

• Quest – Exchange Online Migration
• Quest – On Demand Migration Exchange User Guide

OneDrive.

• Quest – OneDrive Migration documentation
• Quest – OneDrive Migration FAQ

SharePoint.

• Quest – SharePoint Migration
• Quest – SharePoint Migration User Guide

Microsoft Teams.

• Quest – Microsoft Teams Migration
• Quest – Teams and Chat Migration documentation

Active Directory, Entra ID and devices.

• Quest – Active Directory and Entra ID Migration
• Quest – Device Migration
• Quest – On Demand Migration Active Directory User Guide

Coexistence and Domain Rewrite.

• Quest – Domain Rewrite Quick Start Guide

Related Microsoft documentation.

• Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
• Microsoft – Cross-tenant Mailbox Migration
• Microsoft – Cross-tenant OneDrive Migration
• Microsoft – Cross-tenant SharePoint Migration
• Microsoft – Migration Orchestrator
• Microsoft – Power Platform tenant-to-tenant migrations