Consolidating two EMS instances after a merger

A backup carries a complete EMS configuration and endpoint inventory. Restoring it onto the production 7.4 server overwrites that server: the 900 acquirer registrations, profile assignments, tags and logs are replaced by the legacy data. EMS has no merge function, so backup/restore is a one-instance-moves-household tool, not a consolidation tool. Even restoring into a fresh VM does not move the endpoints, because each FortiClient stores the address of the EMS it registered with; the clients keep pointing at the old server regardless of where the database lives.

Sequence:

1. Build the package from the new EMS: FQDN, registration key and locked EMS settings baked into provisioning.
2. Pilot on ten acquired-domain Windows endpoints spanning two OUs, confirming registration, group mapping and profile application.
3. Deploy by rings through Intune in OU-sized batches so a faulty package is stopped early; the install replaces the client and re-points it in one step.
4. Handle macOS separately - the desktop team performs the installs, and you accept slower progress than on Windows.
5. Keep the legacy EMS running during the migration so endpoints stay registered somewhere, then verify zero active registrations for a week before shutting it down and removing its VIP and DNS entries.

Watch for duplicate endpoint records after reimages; reconcile by hostname and serial before reporting completion.

The classic failure is 340 endpoints registering successfully into the wrong group, where they receive no profile or the wrong one.

Pre-flight checks:

• The registration key on the new EMS matches the one built into the package, and the key is treated as a secret - it authenticates devices only, so anyone who obtains it can register a device. Plan to rotate it once provisioning is complete and to alert on unexpected registrations.
• ems.corp.example.com (or the chosen name) resolves from the acquired domain's clients, and TCP 8013 reaches EMS from their networks. The two domains may use different DNS forwarders; test from both.
• Licence capacity covers 1,240 endpoints, not 900.
• The target profile exists, is assigned to the correct group, and the group exists before endpoints arrive; otherwise the first wave lands ungrouped and picks up a default profile.

Directory mapping: verify whether your EMS build can attach a second directory connection. If it cannot, either point the existing connection at a global catalog or a trust, or create manual EMS groups for the acquired estate and assign profiles there. Nested group membership is a common gap - confirm that members of nested groups actually appear on EMS, and test with one real account rather than assuming OU structure equals group structure.

Decommissioning. Do not simply power it off. While it holds registrations, an endpoint that cannot reach its recorded EMS looks unregistered, and anything depending on EMS state - compliance reporting, zero trust tags consumed by a FortiGate - will break unpredictably. Instead: confirm the new EMS shows all 340 devices with recent last-seen times; confirm each client's settings display the new EMS address; reconcile duplicates; export legacy logs if retention rules require them. Then disable legacy logins, leave the VM reachable but idle for about a week as a fallback, and only then power it down and remove its DNS and VIP records so stale clients fail loudly rather than quietly.

The Macs. Without MDM and without local admin rights, users cannot install the client themselves, so zero-interaction migration is not achievable for this group - say so early rather than at quarter end. Options in order of preference: enrol the Macs in an MDM and push a signed package with a pre-configured profile; or have the desktop team perform scheduled assisted installs with temporary admin credentials. Also set expectations on features: several endpoint features offered to Windows endpoints are not available on macOS, so build a macOS-specific profile rather than cloning the Windows one.