What it does

Microsoft's checklist for what to validate and reconfigure after you move, copy or restore the Power Platform environment that hosts Field Service. What comes across depends on the platform operation you chose: a tenant-to-tenant move, a restore or an Everything copy brings solutions and Dataverse data, while a Customizations and schemas only copy brings the schema and users but no application data. Whichever you pick, the environment-specific bits (connections, flows, maps, offline profiles, integrations) still need attention.

Key facts

• Normally carried over with data: Field Service solutions and customisations, configuration data (settings, incident types, price lists, tax codes), transactional data (work orders, bookings, assets) and security role definitions.
• Not safely carried over: connection references and connections, some cloud flows, RSO schedules on a schemas-only copy, mobile offline profile assignments, and anything tied to an external system.
• For a new environment rather than a full copy, the Configuration Migration tool moves configuration and reference data only. It doesn't move the Calendar table or image columns, so work hours and inspection images need a separate route. Use Disable plug-ins in the export schema only where Field Service business logic would interfere with the import.
• Copied RSO schedules keep their Published status but don't run until you re-publish them in the destination. Leave unpublished schedules alone; publishing one starts an optimisation the source wasn't running.
• Azure Synapse Link profiles are deleted by a tenant-to-tenant move and aren't included in a copy or restore.
• A Dataverse organisation linked to a finance and operations environment through dual-write can't be moved to a different tenant, and cross-tenant links aren't supported.
• Business Central needs the connection reconfiguring, Redeploy Integration Solution, and a full sync. Outlook mailbox sync may be deliberately disabled after a copy, because only one environment should sync with Exchange.
• Tenant moves need a case-sensitive usermapping.csv; application users aren't supported in it, and security groups aren't migrated.

When to use / skip

Use it as the cutover runbook any time Field Service moves environment: production-to-UAT refreshes, tenant consolidations after an acquisition, or restoring after a bad deployment. Skip it for a first-time install, where the install page is the right starting point.

Configuration decisions

• Which platform operation fits: tenant move, restore, Everything copy, or schemas-only plus Configuration Migration. This decides how much of the checklist applies.
• Which cloud flows get turned on in the destination. Flows arrive disabled, and turning them on against live connections can message real customers from a test environment.
• Whether the destination is the environment that should hold the Outlook mailbox sync, IoT endpoints and Synapse Link, since each of those is effectively one-environment-only.
• Who owns user mapping and security group rebuilds on a tenant move, and when they're signed off.

Gotchas

• RSO showing Installed after a copy means nothing. Schedules look fine and silently never run until re-published, and a schedule whose recurrence date range has expired shows an empty or past next run time.
• Connection references point at the old environment's connections, so flows fail in odd ways well after go-live rather than at import.
• Solution-aware canvas apps, custom pages and component libraries stop working after a tenant move unless you followed the platform's export-and-remove preparation first.
• A mobile app that signs in to the wrong environment is usually a stale profile or app association, not a Field Service defect.
• Maps settings (Connect to Maps, Auto Geo Code Addresses) can differ after migration. Test address resolution before regeocoding anything in bulk.

Consultant notes

• Run the post-migration checklist as a signed-off UAT script rather than a developer's memory. The Microsoft table is a decent skeleton: apps open, work order created end to end, schedule board loads, geocoding resolves, offline sync completes, integrations behave.
• Do the dry run into a throwaway environment first and time it. Tenant moves in particular have more manual steps than clients expect, and the cutover window gets blown by user mapping rather than data volume.
• Treat the flows and integrations list as a risk register. The costly incidents are a refreshed UAT sending real SMS or emails, or two environments fighting over one mailbox.
• If dual-write to finance and operations is in the picture, raise it in the first workshop. It can rule out a tenant move entirely.

---

Worth another look after the next Field Service release wave, or if Microsoft changes the supported move options.