Kloudeal Journal · Business guide
A Microsoft 365 migration assistant can guide tasks and automate checks, but its scope depends on the product. This guide distinguishes email assistants, specialist platforms and orchestrators to select a tool suited to the business scenario.
Requirements, method selection and guided tasks.
Batches, progress tracking and incident handling.
Dependencies, limits and human validation.
Contents of this guide
What a good migration assistant should provide
| Capability | Why it is useful |
|---|---|
| Discovery | Identifies existing users, mailboxes, sites or workloads before starting. |
| Mapping | Correctly relates source objects to destination equivalents. |
| Pre-migration validation | Detects configurations that could block migration before cutover. |
| Batches and waves | Supports progressive migration of users or resources. |
| Premigration / delta | Where the workload supports it, reduces outstanding data in the final window. |
| Reporting | Distinguishes completion, warnings, errors and outstanding content. |
| Retries | Reprocesses problem objects without repeating the entire project. |
| Post-migration validation | Helps verify that the operation completed correctly. |
These capabilities do not remove the need for architecture design, domain preparation, application reviews or real-user validation.
Need to automate a tenant-to-tenant migration?
Before selecting a platform, we can review both tenants to identify automation opportunities, workloads requiring specific handling and the tool best suited to the project.
Assess my Microsoft 365 migrationWhat a migration assistant should control and which decisions remain human
A Microsoft 365 migration assistant can organise operations, prepare batches and display results, but needs a defined project. It must know which objects to match, which data to transfer and which limits to respect. Incorrect account matching can spread a mapping error across many users quickly when transfer is automated.
Before a batch starts, review its object list and intended destinations. Owners validate exceptions and confirm starting conditions. Approval is particularly important if operations affect the source or require a specific destination state. Use the assistant with these conditions documented and checked.
Automation adds value by repeating a known procedure and producing understandable evidence. The team must know what was attempted, completed and requires intervention. An overall percentage can conceal that a small part of a batch contains the most important business data or permissions.
Using errors to correct the process
Investigate errors before retrying. Locate the object, message and execution stage, then review associated requirements. Correcting a destination account or permission may resolve several failures; repeating transfer without correction adds time and makes reports harder to interpret.
The pilot should also check repeated operations and changed content. Update and resume behaviour depends on method. Retain batches, mappings and results explaining final state at handover. This enables another administrator to investigate incidents without relying on the original operator.
What a Microsoft 365 migration assistant actually is
A Microsoft 365 migration assistant is any tool simplifying and structuring operations needed to move users or information between Microsoft environments. It may be a locally installed application, SaaS platform, configuration wizard or multi-workload orchestrator. Its purpose is to reduce individual manual operations and the separate maintenance of scripts, spreadsheets and logs.
For example, a tool may automatically discover source mailboxes, support selection, match destination users and run several content passes. Another may coordinate Exchange, OneDrive, SharePoint, Teams and identity together. “Assistant” covers very different tools.
| Type | Example | Characteristics |
|---|---|---|
| Workload wizard | CodeTwo | Guides a specific migration step by step, mainly email. |
| Native orchestrator | Microsoft Migration Orchestrator | Coordinates supported workloads and dependencies. |
| SaaS platform | Quest / BitTitan | Projects, workloads, discovery, mapping and reporting. |
| Migration suite | ConnectWise Cloud Migration | Automation and guided migration, particularly for partners and cloud projects. |
| Migration and management platform | ShareGate | Combines Microsoft 365 planning, identity, mailboxes, content and administration. |
What a migration assistant does not do
A simple interface can suggest complete automation, but the tool cannot decide whether a discovered team belongs to a finished project that should be archived. It cannot determine which of 800 GB of documents have legal value or are obsolete copies. It may copy a mailbox without deciding when to transfer empresa.com to the new tenant.
Some decisions remain project responsibilities.
| Decision | Responsible party |
|---|---|
| Which users migrate | Business and IT. |
| Which information is archived | Data owners and compliance. |
| Future identity design | Microsoft Entra ID architecture team. |
| When the domain transfers | Migration team. |
| Application handling | Each application’s technical owners. |
| Permissions to retain | Owners and security team. |
| When results are accepted | IT and key users. |
“Completed” does not necessarily mean users can work. An assistant may report success after copying 30,000 objects. Actual validation then checks that the user: can sign in, send email, open documents, access the correct teams, use critical applications and work with expected permissions.
Wizard, assistant and orchestrator: important differences
These terms are often interchangeable in conversation but describe different technical approaches.
| Approach | What it does | Example |
|---|---|---|
| Wizard | Guides administrators through a configuration sequence. | Create a connection, select mailboxes and launch a job. |
| Assistant | Automates operations and simplifies repetitive decisions. | Automatic matching, provisioning or reporting. |
| Orchestrator | Coordinates related tasks in dependency order. | Migrate Exchange before specific Teams components. |
The last distinction matters. Excellent independent Exchange and OneDrive assistants may still cause problems if nobody controls sequencing. An orchestrator recognises that workloads are not completely independent.
When a guided platform is worthwhile
A sophisticated platform may be unnecessary for three small mailboxes. Benefits increase as users, workloads or dependencies grow.
| Scenario | Assistant value |
|---|---|
| 10 straightforward mailboxes | Moderate. |
| 200 Exchange and OneDrive users | High. |
| Merger involving Exchange, SharePoint and Teams | Very high. |
| Wave-based carve-out | Very high. |
| Multiple tenants and domains | Very high. |
| Identity and device migration | Very high. |
Volume is not the only factor. A 30-user migration can be more difficult than a 300-user project with customised SharePoint sites, hybrid identities, enterprise applications and private Teams channels. Complexity depends on relationships between objects, rather than employee count alone.
Features to require from a migration assistant
Not every feature is necessary in every project, but understand what to compare. Meaningful discovery. Discovery should explain what exists beyond a count of 300 users, identifying workloads and exceptions that could alter scope. Configurable mapping. Automatic matching is useful, alongside controls for exceptions.
The relationship between: nombre.apellido@empresa-a.com and: n.apellido@empresa.com cannot always be inferred without mapping rules. Pre-checks. Identifying problems before migration generally saves more time than merely producing detailed failure logs afterwards. Incremental migration. Deltas are useful where technology and workload support them.
Most information can be copied in advance, leaving changed content for cutover. Some native Microsoft capabilities deliberately use a single move instead. Controlled retries. Large projects encounter blocked objects, permission problems, throttling or unsupported items. Assistants should identify and retry only necessary elements.
Exportable reports
Reports support IT work and formal closure, showing migrated, failed, excluded and manually handled content.
Automation starts with a reliable inventory
If mailbox, OneDrive, SharePoint site, team, guest or application counts are unknown, establish a reliable inventory before configuring an assistant.
Request Microsoft 365 discoveryMicrosoft Migration Orchestrator
Microsoft 365 Migration Orchestrator is Microsoft’s current option for coordinating specific tenant-to-tenant user data migrations. Official documentation still identifies the solution as preview, so recheck availability, licensing and behaviour before production design. Microsoft currently supports four workloads in an orchestrated batch:
| Workload | Orchestrator status |
|---|---|
| Exchange Online Mailbox | Supported. |
| OneDrive | Supported. |
| Teams Chats | Included in the current preview scope. |
| Teams Meetings | Included in the current preview scope. |
Official reference: Microsoft – Migration Orchestrator Overview. A critical distinction: Orchestrator moves content, not identities. Administrators remain responsible for destination user preparation. Migration Orchestrator is not a complete Microsoft Entra ID migration tool. Some content is also excluded. Microsoft currently states that Cross-Tenant User Data Migration does not move shared data from: Teams, Channels and SharePoint Sites.
These need their own strategy.
How Microsoft Migration Orchestrator currently works
Orchestrator’s value is sequencing related workloads. Microsoft recommends running Exchange, OneDrive, chats and meetings together for a migrating user so the orchestrator can manage dependencies. 1. Preparation and identity mapping. Users must exist correctly in both tenants and meet each workload’s requirements.
2. Validation. Microsoft provides a separate, repeatable pre-migration validation phase checking: permissions, inter-tenant relationships, licences and identity mappings. 3. Batch. Users are grouped into batches. Current documentation specifies a maximum of 100 users per batch. 4. Pre-Cutover. Exchange may synchronise before cutover while users continue using the source mailbox.
Microsoft currently recommends submitting batches approximately two weeks before CompleteAfterDate to allow this initial synchronisation.
5. Cutover
When the date arrives CompleteAfterDate, Exchange cuts over before other workloads begin their final move. OneDrive, chats and meetings follow according to selected scope.
Migration Orchestrator is not a complete tenant migration
It is relevant to supported workloads, while business projects may additionally require SharePoint sites, Teams structures, identity, devices, applications, domains and other components. Assess the complete project before deciding whether Orchestrator is the main tool or one part of the solution.
CodeTwo Office 365 Migration
CodeTwo Office 365 Migration is an example of a clearly focused assistant: simplifying Exchange and Microsoft 365 migration without requiring administrators to build the entire procedure in PowerShell. Installed on a computer with tenant connectivity, it uses wizards for source, destination and jobs. What it can migrate between tenants.
CodeTwo primarily focuses on:
| Content | CodeTwo Office 365 Migration |
|---|---|
| Primary mailboxes | Yes. |
| Archive mailboxes | Yes. |
| Yes. | |
| Calendars | Yes. |
| Contacts | Yes. |
| Tasks and other mailbox items | Yes. |
| Public Folders | Yes. |
| SharePoint | Not its purpose. |
| Microsoft Teams | Not its purpose. |
Provisioning and matching. CodeTwo can help create and license destination users and automatically match mailboxes, reducing repetitive work in Exchange-focused projects. Delta Migration. CodeTwo supports further passes for items created after initial migration, enabling mailbox prestaging with less data left for the final window.
When would CodeTwo be appropriate? When email is central and a guided administrative interface is needed without a broader multi-workload platform. If 80 teams and 4 TB of SharePoint must also move, treat CodeTwo as the Exchange component. Official reference: CodeTwo – Microsoft 365 Tenant-to-Tenant Migration.
ConnectWise Cloud Migration: the evolution of the SkyKick ecosystem
SkyKick was a well-known Microsoft partner cloud migration brand. ConnectWise acquired it in 2024 and currently presents these capabilities within ConnectWise Cloud Migration. Updated comparisons should therefore refer primarily to ConnectWise Cloud Migration while explaining its SkyKick heritage. A partner-focused approach. ConnectWise focuses strongly on MSPs and service providers performing recurring customer migrations.
Its current offering includes suites for:
| Scenario | ConnectWise Cloud Migration |
|---|---|
| Exchange → Microsoft 365 | Yes. |
| Microsoft 365 tenant-to-tenant | Yes. |
| Google → Microsoft 365 | Yes. |
| IMAP / POP3 → Microsoft 365 | Yes. |
Tenant-to-tenant. For tenant migrations, ConnectWise currently highlights: discovery, object matching, multiple domains, mapping adjustments when addresses change and staged processes before cutover. Its commercial documentation describes initial synchronisation and a final delta near cutover. When it is particularly relevant. Partner-managed email and Microsoft 365 projects requiring automation of repetitive tasks and consistent workflows across customers.
Before complex multi-workload selection, confirm precisely which workloads the purchased suite covers. Official reference: ConnectWise – Cloud Migration.
ShareGate Migrate: from SharePoint to broader tenant-to-tenant capabilities
ShareGate has changed significantly during 2026. Historically associated with SharePoint, OneDrive and Teams, its current tenant-to-tenant offering describes a broader workflow: identities → mailboxes → content. Identity Migration. ShareGate currently supports preparation and copying of Entra ID users and groups in compatible plans, including mapping, conflict detection, destination identity creation and licensing.
This addresses an important limitation of earlier product versions in tenant-to-tenant projects. Exchange Online. ShareGate has also added mailbox migration. Its current offering covers different mailbox types and supported calendar, contact, online archive, rule and related properties. SharePoint and OneDrive. These remain workloads where ShareGate has particularly extensive experience.
Its approach combines migration with reorganisation, content selection and permission review. Microsoft Teams. ShareGate can work with: teams, standard and private channels, files, permissions, tabs, apps, Planner and associated SharePoint sites, within documented capabilities and limitations. Incremental migration. Further passes transfer changes between waves, fitting projects where users continue working for days or weeks.
When to assess ShareGate
When SharePoint and Teams are significant, particularly where fewer tools are desired across identity, email and content. Official reference: ShareGate – Tenant-to-Tenant Migration.
Comparisons from 2024 or 2025 may already be outdated
Migration Orchestrator, ShareGate, Teams APIs, BitTitan and Quest have changed considerably. Recheck current platform support before purchasing licences for a 2026 migration.
Compare tools for my projectQuest On Demand Migration
Quest On Demand Migration works as a Microsoft 365 migration platform rather than a linear wizard. It focuses on mergers, acquisitions, carve-outs, consolidations and multi-workload projects. Quest currently documents capabilities for:
| Area | Quest ODM |
|---|---|
| Exchange Online | Yes. |
| OneDrive | Yes. |
| SharePoint Online | Yes. |
| Microsoft Teams and Groups | Yes. |
| Power BI | Yes. |
| Microsoft Entra ID / AD | According to purchased plan and components. |
| Devices | Specific capabilities within ODM for AD. |
| Domain Rewrite / Domain Move | Available in specific plans. |
Discovery and collections. Quest discovers environments and organises logical object groups for pilots and waves. Account Matching. User mapping is central, particularly for SharePoint, OneDrive and Teams, whose data and permissions depend on correctly related user objects. Coexistence. Quest provides specific capabilities for tenants collaborating during transition.
This may be decisive in a migration lasting several months. When to assess it. Broad Microsoft 365 projects requiring one console across workloads, identity or coexistence. Official reference: Quest – On Demand Migration.
BitTitan MigrationWiz
MigrationWiz uses projects and migration-type licensing, with administrators configuring projects around the content to transfer. Licence types. BitTitan currently documents options including:
| Requirement | Licence / project |
|---|---|
| Individual mailbox | Mailbox Migration. |
| Mailbox, archive and user documents | User Migration Bundle. |
| Teams | Corresponding Collaboration / Teams project. |
| SharePoint | Shared Document. |
| Microsoft 365 tenant-to-tenant | Tenant Migration Bundle. |
Teams Private Chat. BitTitan revised its Teams Private Chat procedure in July 2026. Current documentation specifies a dedicated project and maximum concurrency of 20 users. This illustrates why Teams support should be checked immediately before a project. When to assess BitTitan. When a mature SaaS platform is needed, particularly for Exchange and associated workloads, with structured projects and extensive documentation.
Official reference: BitTitan – Microsoft 365 Tenant Migration.
Practical comparison of migration assistants and platforms
| Tool | Main approach | Strength | Point to review |
|---|---|---|---|
| Microsoft Migration Orchestrator | Native orchestration. | Coordinates Exchange, OneDrive, chats and meetings within supported scope. | Preview status, excluded identities and unsupported shared data. |
| CodeTwo | Exchange wizard. | Straightforward email, archive and public folder migration. | Does not cover an entire Microsoft 365 tenant. |
| ConnectWise Cloud Migration | Cloud automation for partners. | Discovery, matching, staged migration and repeatable workflows. | Confirm the selected suite’s specific workloads. |
| ShareGate | Tenant-to-tenant platform. | Identity, mailboxes, SharePoint, OneDrive and Teams. | Review exact scope and purchased plan. |
| Quest ODM | Multi-workload platform. | Microsoft 365, identity, devices and coexistence. | Licensing, modules and configuration complexity. |
| BitTitan MigrationWiz | Workload-based SaaS projects. | Exchange, documents and Teams according to licence. | Select the correct project type and bundle. |
When migration is almost entirely email
A platform covering AD, devices, Teams, SharePoint and Power BI may be disproportionate when actual scope is 70 mailboxes. For Exchange-focused scenarios compare:
| Option | May be appropriate when… |
|---|---|
| Microsoft Cross-Tenant Mailbox Migration | The native procedure is preferred and requirements are met. |
| CodeTwo | A guided interface and copy-based delta migration are needed. |
| BitTitan | A SaaS service with a dedicated mailbox project is preferred. |
| Quest | Email is the first phase of a broader migration. |
| ConnectWise | Projects recur within an MSP or partner model. |
When Exchange, OneDrive, SharePoint and Teams are involved
With several workloads, value shifts from isolated support to a consistent way to: discover, map, execute, monitor and validate every workload. Quest and ShareGate are relevant because of their current breadth. BitTitan and other platforms cover several workloads through projects or bundles.
Microsoft Orchestrator may provide a native alternative where supported workloads fit, while SharePoint sites and shared Teams structures need separate assessment.
When Teams and SharePoint are critical
Teams changes tool evaluation. Simply stating a platform migrates Teams is insufficient.
| Ask about… | Why it matters |
|---|---|
| Standard Channels | The basic structure. |
| Private Channels | Specific permissions and SharePoint spaces. |
| Shared Channels | Potential cross-tenant relationships. |
| Posts | Conversation history. |
| Private chats | A separate workload from channel posts. |
| Files | Depend on SharePoint and OneDrive. |
| Planner | More than an ordinary team file. |
| Apps and tabs | May need recreation. |
These scenarios often merit detailed assessment of ShareGate and Quest alongside BitTitan or specialist alternatives according to scope.
When identity must also move
In a merger or carve-out, documents may be only half the work. Other considerations include: users, groups, password strategy, Active Directory, devices, Microsoft Entra Join, Intune and applications. Microsoft Migration Orchestrator does not migrate identities by itself. Quest has specific Active Directory and Entra ID capabilities.
ShareGate added cross-tenant identity copying during 2026 in Pro and Enterprise plans. Identity requirements can therefore significantly influence tool selection.
When tenants must coexist for weeks or months
A strong data-copying tool may not be the best choice for a six-month transition. Long waves also require consideration of: mail routing, free/busy, Teams collaboration, document access, identity synchronisation and user experience. Quest provides features for specific coexistence scenarios. Microsoft supports coexistence through several services and configurations, usually requiring separate design and coordination.
How far automation should extend
Automating repetitive tasks is useful. Automating poorly understood decisions creates risk. Suitable automation. Good candidates commonly include: discovery, rule-based matching, job creation, retries, log exports and reporting. Decisions requiring human oversight. In particular: ambiguous mappings, duplicate users, content deletion, sensitive permissions, domain changes and acceptance.
Tools should reduce mechanical work so technical teams can focus on these exceptions.
Permissions granted to the assistant
Permissions deserve as much attention as features. A tenant migration tool may need to read and write: email, documents, groups, SharePoint, chats, teams and identities. Before granting consent, review:
| Question | Purpose |
|---|---|
| Which App Registrations are created? | Document migration applications. |
| Which Graph permissions are requested? | Understand actual access scope. |
| Are application permissions used? | Assess access without a signed-in user. |
| Can scope be restricted? | Apply least privilege where possible. |
| Are service accounts needed? | Manage and protect them appropriately. |
| What will be removed afterwards? | Close the project properly. |
Decommissioning belongs in project scope. At completion, review: Enterprise Applications, App Registrations, service accounts, temporary users, certificates and consent grants used exclusively for migration.
Recommended process when using a migration assistant
Tool selection should follow assessment. 1. Analyse the environment. Inventory users, mailboxes, OneDrive, SharePoint, Teams, domains, applications, identity and legal requirements. 2. Define scope. Document content to migrate, archive, recreate or exclude. 3. Select architecture. Decide identity, domains, coexistence, workload sequence and cutover model. 4. Select tools.
Compare platforms against actual scope. 5. Prepare permissions. Authorise source and destination access and document exact grants. 6. Run tool discovery. Compare results with the initial inventory to identify discrepancies. 7. Mapping. Automatically resolve straightforward cases and manually review ambiguous ones. 8. Pilot. Use representative cases, including difficult users.
9. Premigration. Where supported, transfer most data before cutover. 10. Waves. Migrate users and workloads under controlled conditions. 11. Cutover. Coordinate identity, domain, DNS, Exchange and applications through the runbook. 12. Validation. Combine tool reporting and functional tests. 13. Hypercare. Maintain enhanced support during initial days. 14. Decommission. Remove temporary permissions and close the source only when the project permits.
Why a pilot remains essential with an assistant
Documentation describes supported features. The pilot demonstrates results with your data.
| Case | What to check |
|---|---|
| Standard mailbox | Normal operation. |
| Mailbox with archive | Licensing and historical content. |
| Shared mailbox | Permissions and delegation. |
| Large OneDrive | Performance and sharing. |
| Complex SharePoint | Metadata, permissions and versions. |
| Team with a private channel | Permissions and associated SharePoint. |
| Teams chats | Historical fidelity. |
| Application user | SSO and dependencies. |
Changing tool or using a different combination after the pilot is a valid outcome.
Common mistakes when using migration assistants
| Error | Effect | Prevention |
|---|---|---|
| Assuming the assistant designs the project | Technically executed but poorly designed migration. | Design architecture first. |
| Selecting tools before discovery | The product does not cover the complete scope. | Inventory first. |
| Blindly trusting automatic matching | Incorrect user relationships. | Review exceptions. |
| Ignoring current limitations | Unsupported content is promised. | Consult current documentation. |
| Confusing Orchestrator with a complete tenant move | SharePoint sites, Teams structures or identities remain excluded. | Separate included and excluded content. |
| Selecting CodeTwo for a Teams project | Other workloads lack a migration tool. | Use it for its strength: Exchange. |
| Ignoring SkyKick’s current product | Outdated names or documentation are used. | Consult ConnectWise Cloud Migration. |
| Skipping the pilot | Limitations emerge in production. | Test complex cases. |
| Ignoring granted permissions | Unnecessary access remains afterwards. | Plan least privilege and decommissioning. |
| Closing at “Completed” | Users discover incidents later. | Functional validation and hypercare. |
Checklist before purchasing a Microsoft 365 migration assistant
| Question | Questions to answer before purchasing |
|---|---|
| How many users? | Yes. |
| How many mailboxes and archives? | Yes. |
| How many shared mailboxes? | Yes. |
| How much OneDrive data? | Yes. |
| How many SharePoint sites? | Yes. |
| How many teams and channels? | Yes. |
| Are chats required? | Yes. |
| Is identity hybrid? | Yes. |
| Are devices included? | Yes. |
| Are enterprise applications involved? | Yes. |
| How long will coexistence last? | Yes. |
| Which domain transfers? | Yes. |
| What fidelity is required? | Yes. |
| Are deltas needed? | Yes. |
| Which permissions does the tool require? | Yes. |
| How is it licensed? | Yes. |
| How will results be validated? | Yes. |
Frequently asked questions about Microsoft 365 migration assistants
Does a migration assistant choose data destinations itself?
It may offer defaults and guidance, but destinations must follow approved design. Review identity relationships, locations and permissions before execution. Automation does not correct a wrong decision and may spread its effects across many objects.
What should be checked before launching a batch?
Review objects, destinations, method requirements and exceptions. Confirm appropriate permissions and licences. Assign success criteria and a validation owner, particularly where execution changes the source or affects later operations.
Should errors be retried until they disappear?
Understand the cause and repeat behaviour first. Errors may require changes to preparation, access or content; others indicate limitations. Undiagnosed retries can create duplicates or confuse reports. Test correction on a sample before expanding to the affected batch.
Which evidence should administrators retain?
Keep mappings, executed batches, reports and decisions explaining result differences. Document important requirements and corrective steps. This supports acceptance and later troubleshooting beyond dashboard screenshots or operator memory.
Final recommendations: the best assistant automates the right project
A Microsoft 365 migration assistant can save hundreds of manual operations when used within well-designed architecture. Microsoft Migration Orchestrator coordinates Exchange, OneDrive, chats and meetings with workload dependencies, but remains in preview and does not represent complete tenant migration.
CodeTwo is relevant for Exchange-focused projects needing guided matching, provisioning, jobs and deltas. ConnectWise Cloud Migration continues SkyKick’s automation approach for partners requiring repeatable processes. ShareGate has broadened its tenant-to-tenant offering across identities, mailboxes and content.
Quest On Demand Migration supports complex multi-workload Microsoft 365, identity, device and coexistence projects, while BitTitan uses established SaaS projects and workload licensing. Selection should start beyond the question “Which assistant is best?”. Ask instead: What must migrate, what exactly must be preserved and which operations should be automated while retaining project control?
Once those questions are answered, tool selection becomes clearer.
Need to select or configure a Microsoft 365 migration assistant?
In Kloudeal we can assess the environment before licence purchase and identify a platform suited to actual scope. We work with Exchange Online, OneDrive, SharePoint, Microsoft Teams, domains, Microsoft Entra ID, hybrid identity, applications, permissions and coexistence. We can use Microsoft native capabilities or specialist tools such as Quest On Demand Migration, ShareGate, BitTitan, CodeTwo or ConnectWise Cloud Migration, selecting one platform or a combination where technically appropriate.
Talk to Kloudeal about my Microsoft 365 migrationRecommended official documentation
Microsoft Migration Orchestrator.
- Microsoft – Migration Orchestrator Overview
- Microsoft – Preparing Users for Migration Orchestrator
- Microsoft – Running a Migration with Migration Orchestrator
- Microsoft – Migration Orchestrator FAQ
- Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration
CodeTwo Office 365 Migration.
- CodeTwo – Office 365 Migration
- CodeTwo – Tenant-to-Tenant Migration
- CodeTwo – Microsoft 365 Tenant-to-Tenant Walkthrough
ConnectWise Cloud Migration.
ShareGate.
- ShareGate – Tenant-to-Tenant Migration
- ShareGate – Exchange Online Mailbox Migration
- ShareGate – Entra ID Migration
- ShareGate – Microsoft Teams Migration
- ShareGate – Migrate Release Notes
Quest On Demand Migration.
- Quest – On Demand Migration
- Quest – On Demand Migration User Guide
- Quest – On Demand Migration Release Notes
BitTitan MigrationWiz.
- BitTitan – Microsoft 365 Tenant Migrations
- BitTitan – Which Migration License Do I Need?
- BitTitan – Teams Private Chat Migration Guide
Evaluating an assistant with your own migration cases
A product demonstration is a useful starting point, but the evaluation should move quickly to cases from the actual environment. Prepare a short description of the intended result before opening the tool. Include the source objects, destination accounts, data types and working behaviours that matter. This gives the technical team a reference for deciding whether a feature is relevant rather than being guided only by the order in which the product presents its screens.
Separate essential requirements from conveniences. A clear dashboard may reduce effort, but it does not compensate for a missing workload or an unsupported permission relationship. Conversely, a powerful platform may introduce unnecessary configuration if the project only requires a small set of straightforward mailbox transfers. The evaluation should explain the connection between each important requirement and the capability used to meet it. This makes the final choice reviewable by someone who did not attend the demonstration.
Start with discovery and object selection
Compare the tool’s discovered inventory with the project inventory. Investigate differences instead of assuming that either list is complete. A tool may display objects according to its own supported scope, while the project inventory includes dependencies it does not migrate. Record which objects are visible, which are selectable and which require another procedure. These distinctions help avoid interpreting absence from a screen as evidence that the business does not need the resource.
Review how selection is organised. The team should be able to understand which users and resources belong to a pilot or wave and why. Check how exceptions are represented and how the selection can be reviewed before execution. A saved batch should provide a clear description of the intended work. If administrators cannot explain the batch contents without reconstructing their memory of several screens, the process needs additional documentation.
Test matching through known exceptions
Use an ordinary matching case and at least one case requiring an explicit decision. A renamed user, different address pattern or destination account already in use can reveal how much control the administrator has. Confirm the intended relationship with the project owner before running the operation. Automatic matching is valuable when its rules are understood and its exceptions are visible. It becomes less useful when the team cannot tell how a proposed relationship was selected.
Keep mapping decisions separate from the mechanics of executing them. The business and identity design establish which account represents the person. The platform applies that relationship to supported operations. This distinction matters when several workloads use the same mapping. Correcting one correspondence should trigger a review of the affected operations rather than an assumption that every earlier result automatically changed with it.
Observe what happens when a requirement is unmet
During a controlled pilot, examine the messages produced by a preparation problem that the team understands. The purpose is to assess whether the tool makes the affected object, stage and next investigation clear. A useful error record helps administrators distinguish an access problem, an invalid destination state and unsupported content. An unexplained failure count may require more manual investigation and should be reflected in the operational effort estimate.
Then correct the known condition and test the supported retry procedure. Record what is repeated, what is retained and what the tool reports afterwards. Do not infer repeat behaviour from the appearance of a retry button. The project needs to understand the method’s documented treatment of existing or changed content. This information belongs in the operating procedure used for production waves, particularly when several people will administer the platform.
Check reports against acceptance questions
Ask whether the reports answer the questions needed for handover. The team should be able to identify completed work, warnings, failures, exclusions and outstanding action at a useful level. A total transferred size may support capacity analysis, while a list of affected objects supports correction. Neither replaces functional tests. Map each report to the decision it supports so that evidence is collected for a purpose rather than exported without interpretation.
Use the pilot to connect technical reports to a real working journey. A mailbox owner sends and receives messages, a delegate opens the intended shared resource and a document owner accesses a representative repository. If the platform reports success but a journey fails, investigate the gap. The result may identify a separate configuration task, an excluded dependency or an incorrect expectation. All are relevant to choosing the complete solution.
Plan administration and closure alongside execution
Review who will operate the tool during the project and who can make consequential decisions. Routine job monitoring, mapping approval, scope changes and acceptance are different responsibilities. A clear allocation prevents the platform’s available buttons from becoming the decision process. It also helps an administrator recognise when an exception should be escalated rather than resolved by changing the batch until it appears to run.
Document the access used by the platform, its purpose and the planned closure review. The technical record should identify applications and accounts without embedding secrets. At completion, the responsible team checks which access remains necessary and which was temporary. This is part of an orderly handover, especially when a client’s administrators will continue operating the destination after the migration provider’s involvement ends.
Compare total effort, not only the licence
The evaluation should include preparation, operator time, exception handling, reporting and any work performed outside the tool. A low licence price can still accompany substantial manual reconstruction. A broader platform may reduce separate tasks, but that benefit should be demonstrated with the project’s requirements. Record assumptions clearly so that the comparison remains useful if scope changes. The purpose is to select a workable approach, not to produce a universal ranking.
At the end of the pilot, write a brief decision record. State the scenario, the requirements tested, the observed results, limitations and the remaining work. Explain why the chosen platform or combination fits those findings. This document gives the project a defensible basis for proceeding and gives later operators enough context to understand why the workflow was designed in that particular way.
Repeat the evaluation when an important requirement changes. A platform selected for email alone may need reassessment if identity, shared content or a longer coexistence period enters scope. The earlier decision record provides the starting point for that review, showing which assumptions remain valid and which new cases must be tested before the workflow is extended.