Migrating a Multi-Site AEM 6.5 Estate to Cloud Service
A financial services firm runs AEM 6.5 on-premise with 12 sites managed via MSM live copies, a custom replication agent that pushes content to a legacy search appliance, and 8 custom OSGi services. Assets total 4 TB. They must move to AEM as a Cloud Service within 12 months. Constraints: regulatory requirement that no content leaves the region; a hard freeze on the legacy search appliance until Q3; 30 authors who cannot tolerate more than a 1-day cutover. An audit flags that several custom services write directly to the JCR outside service users and one uses a deprecated API removed in Cloud Service.
1. Sequence the migration and identify which items block Cloud Service and which can be deferred.
Read the worked answer
Hard blockers (must fix before migration):
- Custom service writing to JCR outside service users → must be refactored to use service users with least privilege; Cloud Service enforces this and it's also a security finding.
- Deprecated API removed in Cloud Service → must be rewritten; no workaround.
- Region constraint → drives choice of Cloud Service region and data residency review; confirm the approved region before any migration work.
Deferrable / parallel:
- Legacy search appliance replication agent: keep it running against 6.5 until the Q3 freeze lifts, then replace with a Cloud Service-compatible integration (e.g., a supported connector or event-driven export). This does not block the AEM migration if search is decoupled.
- MSM live copies: migrate as-is; MSM is supported on Cloud Service. Validate rollout configs, which behave differently.
- 4 TB assets: migrate via the supported asset ingestion path in batches; not a blocker but a long pole-start early.
Sequencing: (1) region + residency sign-off; (2) refactor the two blocking services; (3) asset migration dry runs; (4) content + MSM validation; (5) cutover; (6) search integration swap after Q3.
2. How do you achieve a 1-day cutover for 30 authors while honoring the search-appliance freeze?
Read the worked answer
Decouple search from the cutover. Because the legacy appliance must stay frozen until Q3, do not make it a cutover dependency. Options:
- Run the appliance against the old 6.5 instance in read-only mode for the freeze period, or
- Stand up a temporary index from an export so authors' search still works during the gap, then swap to the new integration after Q3.
Cutover plan for authors:
- Rehearse the full cutover at least twice on a staging environment with real content volume; measure actual downtime.
- Pre-stage content and assets so cutover is a delta sync, not a full 4 TB copy.
- Freeze authoring for a short window (target ≤8 hours), not a full day, by doing the heavy sync beforehand.
- Author acceptance test immediately post-cutover: log in, edit, publish, verify on publish tier, check MSM rollout.
- Rollback: keep 6.5 read-only and reversible for 72 hours; documented revert if author acceptance fails.
The 1-day tolerance is about author-visible disruption, so minimize the authoring freeze window and hide backend work behind it.
3. What governance and validation would you put around the refactored custom services before go-live?
Read the worked answer
- Service-user model: each service gets a dedicated service user with a minimal permission set; no admin or anonymous JCR writes. Document the mapping service→permissions.
- Code review + static analysis: scan for direct JCR writes and deprecated APIs in CI; block merges on findings.
- Integration tests in a Cloud Service-like environment: the deprecated API may behave differently; test in the actual Cloud Service stage, not just local SDK.
- Security sign-off: the audit finding must be formally closed with evidence (config + tests), given the financial-services context.
- Observability: ensure the services emit logs/metrics compatible with Cloud Service logging so failures are visible post-migration.
- Change control: freeze service changes during the cutover window; any post-go-live change follows the same review gate to prevent regression.