Migration: 54 questions, answered straight.

In most cases, yes. A CSP transfer is usually a change to the partner, billing, and support relationship, not a tenant migration, so users, data, and workloads remain in the same Microsoft tenant. IT Partner should still review the current subscription type, NCE term, renewal date, seat counts, and license assignments before the change to avoid access gaps or duplicate purchases.

A CSP relationship change does not normally move your tenant, delete data, or change the Microsoft service being used. The underlying entitlement should remain the same when the same SKU, term, and billing option are available. The final quote can still vary because of taxes, currency, promotions, partner services, or NCE commercial terms.

Usually no. Microsoft licenses provide entitlement to use the cloud service; migration, configuration, data mapping, integrations, testing, and user adoption are separate services unless explicitly included in a scoped engagement. IT Partner can assess the source system and define a migration project when data needs to be moved.

A migration engagement usually starts with kickoff, discovery, and a source-environment health check. IT Partner then prepares identities, licenses, target workloads, migration batches or tools, validation steps, cutover timing, and post-migration tasks. Progress is monitored throughout the project so issues can be addressed before final acceptance.

IT Partner typically handles discovery, migration planning, destination configuration, migration tool setup, batch execution, progress monitoring, troubleshooting, validation, and the project closeout report. Depending on scope, IT Partner may also configure users, assign licenses, validate domains, prepare Exchange Online, configure SharePoint structures, or set up Azure migration components. Items outside the agreed scope must be added separately.

The customer must provide a dedicated point of contact, required administrative access, source-system information, scheduling input, and timely approvals. The customer is also responsible for coordinating third-party vendors, making or authorizing DNS changes, supporting firewall/network changes, identifying high-risk users or workloads, and communicating planned changes to end users. Delays in access, DNS, vendor coordination, or approvals can affect the migration schedule.

Prerequisites depend on the workload, but typically include an active Microsoft tenant, correct licensing, administrative access to source and destination environments, verified domains, network readiness, and an approved destination design. For identity-dependent projects, Entra ID readiness and any directory synchronization requirements should be reviewed. Critical workloads should also have a rollback or recovery plan before cutover.

IT Partner designs migrations to minimize disruption, but downtime depends on the workload, data volume, source system, cutover approach, DNS timing, network bandwidth, and user profile or device changes. Email and file migrations often use staged or incremental synchronization to reduce impact. Any expected service interruption should be documented during planning rather than assumed to be zero.

Validation usually checks that migrated data is complete, usable, and mapped correctly in the destination. For collaboration workloads, this may include files, folders, metadata, permissions, group access, mail flow, calendars, contacts, and representative user access. Success criteria should be agreed before migration so both teams know what will be tested and accepted.

After cutover, IT Partner performs validation against the migration plan, reviews outstanding issues, and provides closure or follow-up communication. The customer confirms that required data, access, and workload functionality are acceptable. Any additional remediation, training, decommissioning, or optimization work should be handled under the agreed scope or a follow-on project.

A standard email migration usually does not include OneDrive, SharePoint, Teams content, Teams chat history, Planner, Power Platform assets, public folders, PST ingestion, third-party archives, endpoint repair, user training, source-tenant decommissioning, or identity redesign unless separately scoped. Advanced mail-flow redesign, complex SMTP relay remediation, and full DKIM/DMARC/SPF policy redesign may also require separate work. The exact exclusions should be confirmed before kickoff.

Post-migration support normally focuses on issues directly related to the migration, such as mail-flow validation, access problems, missing-item investigation, DNS follow-up, or workload validation. The duration, support hours, escalation process, SLA coverage, after-hours support, endpoint repair, and unrelated Microsoft 365 administration should be confirmed in the statement of work. Extended hypercare can often be scoped separately.

High-risk users such as executives, VIP users, heavily delegated mailbox users, and users with very large mailboxes should be identified early. They may require special scheduling, additional validation, or closer communication during cutover. This helps reduce business impact for the people and mailboxes most likely to affect operations.

A typical approach uses initial synchronization followed by incremental synchronization so new mail continues to be captured before cutover. During the final cutover, DNS records such as MX, Autodiscover, SPF, DKIM, and related mail-routing settings may be updated as required by the plan. IT Partner validates that mail can be sent and received through Exchange Online after the change.

Email can often be migrated to Exchange Online from Exchange Server, another Microsoft 365 tenant, IMAP systems, Google Workspace, or hosted email providers. The right method depends on mailbox count, mailbox size, coexistence needs, identity configuration, source-platform limits, and cutover timing. IT Partner can recommend a staged, cutover, hybrid, IMAP, or tenant-to-tenant approach based on discovery.

The timeline depends on the number and size of mailboxes, source-system health, bandwidth, coexistence requirements, DNS access, and customer availability. Some smaller cutover projects can be completed quickly, while larger or more complex environments require staged migration and extended validation. IT Partner should confirm the schedule after discovery rather than relying on a generic duration.

Exchange Online Protection is commonly validated as part of an Exchange Online migration, especially for basic inbound and outbound mail flow. However, advanced anti-spam, anti-phishing, anti-malware, compliance, quarantine, and transport policy design should be explicitly scoped. Customers with strict security or compliance requirements should define those requirements before cutover.

Typical prerequisites include a Microsoft 365 tenant, appropriate Exchange Online licenses, access to DNS for the email domain, administrative access to the source Exchange environment, and a healthy source mail system. If hybrid or remote-move methods are used, certificates, connectivity, supported Exchange versions, and directory synchronization with Entra ID may also matter. IT Partner confirms the exact prerequisites during discovery.

When included in scope, IT Partner can create Microsoft 365 users, assign Exchange Online licenses, validate domains, and prepare destination mailboxes. In existing tenants, account matching and license assignment must be planned carefully to avoid duplicate users or conflicts. Identity design and directory synchronization changes may require separate scoping.

Tenant-to-tenant migrations typically require administrative access to both the source and destination Microsoft 365 tenants. The exact roles depend on the migration method, but permissions are needed to assess mailboxes, configure migration endpoints, map users, manage domains, and validate mail flow. Access should be granted securely and removed or reduced after the engagement.

A tenant-to-tenant mailbox migration typically includes discovery, user and mailbox mapping, destination preparation, migration batch setup, synchronization, cutover planning, validation, and closeout reporting. Depending on scope, it may also include domain move planning, mail-flow transition, and Microsoft 365 Group mailbox migration. Teams, SharePoint, OneDrive, Planner, Power Platform, and compliance data are separate workloads unless explicitly included.

Microsoft 365 Group migration may be possible, but it should be treated as a defined workload within a tenant-to-tenant project. Group mailboxes, membership, permissions, Teams-connected content, and SharePoint-connected files can have different migration requirements. IT Partner should confirm what group components are included before migration begins.

A Google Workspace migration usually begins with source verification, Microsoft 365 tenant preparation, user and license setup, migration mapping, and staged data transfer. Email, calendars, and contacts may be migrated depending on scope, followed by MX cutover and post-migration validation. Google Drive, shared drives, and permissions require separate planning if they are included.

A standard Google Workspace email migration usually does not include Google Drive migration, SharePoint document migration, Teams rollout, desktop software configuration, user training, or documentation beyond the project closeout report unless separately scoped. Shared drives, complex permissions, and large archives can significantly change the project. These should be reviewed before the engagement begins.

A SharePoint migration requires appropriate Microsoft 365 licensing, administrative access to the source and destination, a planned site and library structure, and agreed permissions and metadata requirements. Source content should be inventoried for size, ownership, sensitivity, and obsolete material. Network capacity and migration windows should also be reviewed for large data volumes.

IT Partner typically assesses the source environment, prepares the migration project, configures migration tools, maps users and permissions, migrates content, validates structure and access, and provides a closeout report. When included, IT Partner may also help decommission old libraries or source locations to prevent users from continuing to work in the wrong system. SharePoint design, governance, and custom development should be scoped separately if needed.

A standard SharePoint migration usually does not include user training, custom SharePoint development, extensive information architecture consulting, mail migration, endpoint software settings, or documentation beyond the closeout report unless specified. Workflow modernization, Power Platform remediation, retention design, and advanced governance may also require separate work. Confirm these items before kickoff if they are required.

A OneDrive migration typically maps source users to destination users, prepares destination OneDrive locations, transfers files, and validates ownership and access. The migration plan should account for file volume, sharing links, permissions, blocked file types, and user communication. Desktop sync client configuration and endpoint troubleshooting are separate unless included in scope.

A standard OneDrive migration generally does not include email migration, user training, broad consulting, desktop software configuration, or extensive documentation beyond closeout reporting. Rebuilding user devices, remediating OneDrive sync client issues, and redesigning file-sharing governance may require additional services. Confirm whether external sharing links and permissions are in scope.

Teams migration can be planned, but Teams is a composite workload that may include teams, channels, memberships, files in SharePoint, meeting artifacts, apps, tabs, and compliance data. Chat history and some application data may have limitations depending on tools, licensing, and Microsoft APIs. IT Partner should assess Teams requirements separately from mailbox migration.

Standard Teams migration or rollout services may exclude Teams user training, Skype for Business removal from mobile devices, operating system updates, PSTN integration, phone-system configuration, rollout communications, and extensive documentation. Teams apps, custom tabs, recordings, chats, and compliance retention should also be explicitly scoped. Confirm the exact deliverables before project start.

Metadata and permissions should be mapped during planning so the destination reflects the intended ownership, structure, and access model. IT Partner validates representative migrated content to confirm that files, folders, metadata fields, and permissions transferred as expected. Some legacy permissions or source-specific sharing links may need remediation or redesign.

Cloud file migrations typically require administrative access or approved migration permissions for both the source platform and Microsoft 365 destination. IT Partner needs these permissions to discover content, map users, preserve permissions where possible, and execute the migration. Access should be time-bounded and governed according to the customer’s security policies.

Source decommissioning should be planned, not assumed. After validation, organizations may need to disable old access, update bookmarks and integrations, remove legacy mail flow, cancel old subscriptions, and retain data for legal or compliance reasons. IT Partner can assist when decommissioning is included in scope.

A device or profile migration usually includes discovery, migration strategy, tool configuration, test migration, profile or settings transfer, Entra ID join or registration validation, application access checks, and residual issue resolution. The exact scope depends on whether devices are being moved to Microsoft Entra ID, Intune management, or a new tenant. User communication and scheduling are critical to reduce disruption.

Some user impact is possible during device enrollment, profile transition, application validation, sign-in changes, or troubleshooting. Automation and standardized processes can reduce disruption, but timing should be planned around user availability and business operations. High-priority users and shared devices should be identified early.

IT Partner typically handles discovery, migration strategy, migration tool configuration, device or profile migration tasks, Entra ID validation, and migration-related support. The customer provides environment access, device inventory, user information, readiness decisions, scheduling input, and feedback on results. Conditional Access, security baseline redesign, and application packaging may require separate scoping.

An Azure migration assessment usually inventories source workloads, reviews dependencies, estimates target sizing, and identifies readiness or risk items. IT Partner may prepare Azure migration components, replication infrastructure, and assessment reporting depending on the engagement. The output helps decide migration waves, target architecture, and expected Azure costs.

IT Partner reviews workload role, dependencies, downtime tolerance, size, load, configuration needs, and transfer method before migration. The migration plan is then designed to reduce disruption through sequencing, testing, replication, and defined cutover windows. This minimizes risk but does not guarantee zero downtime for every workload.

A SQL Server to Azure VM migration typically includes preparing the Azure VM, configuring SQL Server, setting up connectivity, copying or restoring databases, validating the deployment, and resolving migration-related issues. Supported version upgrades may be included when defined in scope. Application remediation, performance tuning, high availability, and long-term managed services should be scoped separately.

SQL migration duration depends on database size, downtime tolerance, compatibility issues, backup and restore strategy, network throughput, testing needs, and application cutover complexity. Smaller migrations can be completed quickly, while complex databases or critical applications require more planning and validation. IT Partner should provide a project schedule after assessment.

Standard SQL migration scope may exclude application code remediation, detailed network redesign, high availability architecture, performance tuning, reporting redesign, security hardening, and post-migration managed services unless explicitly included. Documentation beyond the project closeout report may also require additional scope. Confirm these needs before migration begins.

Depending on requirements, SQL Server to Azure SQL Database migration may use compatibility assessment, schema remediation, transactionally consistent copies, export/import methods, replication, or other Microsoft-supported migration approaches. The right method depends on downtime tolerance, database compatibility, size, and application dependencies. Connection string changes and application validation should be planned as part of cutover when included.

Yes. Critical systems should have verified backups, snapshots, recovery points, or rollback plans before migration or cutover. The customer and IT Partner should agree who is responsible for backup creation, retention, restore testing, and recovery decisions.

DNS changes are often performed by the customer or the customer’s DNS provider, with IT Partner providing the required records and timing guidance. Email migrations may require MX, Autodiscover, SPF, DKIM, DMARC, and related record updates, while other workloads may require domain validation or service-specific records. DNS ownership and change windows should be confirmed before cutover.

Yes, public folders can be migrated, but they require careful assessment of folder size, hierarchy, permissions, mail-enabled folders, and business usage. Large public folder environments may need staged migration and validation. Pricing and timeline are usually affected by total data volume and complexity.

PST ingestion and third-party archive migration are not usually part of a standard mailbox migration unless explicitly scoped. These projects require inventory, chain-of-custody or compliance review, deduplication decisions, and destination planning. IT Partner should assess archive size, retention requirements, and target mailbox or archive design before quoting.

Yes, but it is an implementation and data-migration project rather than a license entitlement. Source data must be profiled, mapped, cleansed, imported, validated, and reconciled with security roles, workflows, integrations, and reporting requirements. IT Partner should assess data quality and business process requirements before committing to timeline or scope.

Possibly, but Planner, Project for the web, Project Online, Project desktop, and spreadsheets use different data models and capabilities. Migration should start with an inventory of projects, dependencies, custom fields, reports, attachments, permissions, and required views. Some work may require manual conversion, staged rollout, or a higher Project plan.

Yes, existing Visio files can usually be stored in OneDrive or SharePoint and opened with the appropriate Visio plan. File compatibility depends on features used, because some advanced desktop-only capabilities may not be editable in the web experience. Deployment planning should confirm app rights, version compatibility, and endpoint policies.

Many Microsoft add-ons are licensing and configuration changes rather than data migrations. For example, security, compliance, capacity, or analytics add-ons may require policy design, role assignments, stakeholder review, and validation, but not a tenant move. If the add-on replaces another tool, migration of settings, workflows, evidence, or historical data should be scoped separately.

Government and nonprofit customers should confirm eligibility, tenant cloud type, SKU availability, NCE term, renewal timing, compliance requirements, and any restrictions tied to their current subscription. A CSP transfer should not normally move the tenant, but licensing continuity must be planned carefully. Government environments may also require additional review for data residency, access controls, and compliance obligations.

Migration pricing depends on scope, workload type, number of users, data volume, source complexity, destination design, cutover requirements, and support expectations. Some services may be priced per mailbox, per GB, per workload, or as a fixed scoped project. IT Partner should confirm final pricing after discovery and provide a written quote before work begins.

Typical success criteria include users being able to access Exchange Online, migrated mailboxes being available, mail flow working through Microsoft 365, required transport rules functioning, and Exchange Online Protection operating at the agreed baseline. Additional criteria may include calendar, contact, delegation, mobile, and desktop access validation. These criteria should be documented before cutover.