Guide · updated
Testing an AEM migration: visual regression, content QA and UAT
A migration is successful when nobody notices it: pages look the same, authors work the same way, integrations keep running. Testing is how you prove that, and it is the phase most often squeezed at the end. Plan it from the start.
Layer 1: automated checks on every build
- Unit tests for custom Java code, which Cloud Manager's Code Quality step also measures (coverage below 50% pauses a pipeline).
- Visual regression on a fixed list of URLs per template, old site against new, with a tolerance for intentional differences.
- Link, status-code and redirect checks across the old URL list.
- Metadata checks: title, description, canonical, hreflang and structured data per page.
Layer 2: content QA by sampling
After each content transfer, check a sample per template and per language: text, images and renditions, links, components that rely on custom data. Size the sample so every template and every content owner's area is covered at least once, and add the pages that matter most commercially.
Layer 3: authoring and UAT
- Write author scenarios per template: create, edit, publish, translate, roll back.
- Run them with real authors on stage, with production-like content.
- Log defects with a severity agreed in advance: what blocks go-live and what can follow.
- Repeat after the last content top-up on a short checklist, not the full suite.
Performance and integrations
- Load-test the publish tier and CDN with realistic traffic shapes and cache hit rates.
- Test each integration end to end, including failure behaviour: outgoing calls need timeouts on Cloud Service.
- Check search, forms and personalisation separately; they often depend on configuration rather than code.
Our factory drafts a test plan per page template from its definition (run on our own AI server), which a QA engineer then reviews and completes.