Surge Migrate

Free tool · no sign-up · runs locally

AEM Cloud Service readiness scan

Find out what in your AEM 6.5 estate blocks a move to AEM as a Cloud Service, how much work it is, how much of it agents can take on, and which service fits.

  • Nothing is uploaded. Files are read by JavaScript in this browser tab.
  • Three ways in. A Best Practices Analyzer CSV, a repository zip, or eight quick questions.
  • Every finding explained. 33 code rules and 31 BPA codes, each with file and line, the fix and how automatable it is.
  • Same input, same result. The scan is deterministic; the effort method is shown below.

Option A: Best Practices Analyzer report

In AEM: Tools → Operations → Best Practices Analyzer → Export to CSV. Drop the results.csv here.

Option B: your code repository

Zip the project folders (core, ui.apps, ui.config, dispatcher). Build output and node_modules are skipped.

No files to hand? Answer 8 questions instead (about 1 minute; gives a rougher estimate)
Do you use any of these?
The sample is synthetic data in Adobe's CSV format, not a real customer.

Methodology

How the estimate works

The scan is deterministic: the same input always gives the same result. It reads your input in one of two modes, then prices each finding type with open planning hours.

Repository mode

33 rules look for code and configuration patterns that Adobe documents as removed, unsupported or deprecated on AEM as a Cloud Service: removed APIs, administrative logins, Classic UI dialogs, Foundation components, custom run modes, mixed content packages, legacy OSGi config formats, Oak index definitions, DAM workflow customisations and more. Each finding links to a page explaining the fix.

BPA mode

Your Best Practices Analyzer rows are grouped by pattern code (31 codes recognised), INFO rows are treated as inventory, and each group takes its worst importance level.

Readiness score

The score falls with each distinct blocker, major and minor finding type, and logarithmically with volume.

  • Hours per finding type. Each finding type has planning hours per affected file plus a fixed cost, capped. The values are in our open rule set.
  • Fixed project work. Every migration also carries 164 hours of fixed work, shown alongside.
  • An agent-assisted target. It assumes agents take on 75% of highly automatable work, 40% of partly automatable work and 10% of the rest, with review time charged back. It is a target for our pipeline, not a measured result.
  • What the scan cannot see. Content volume and quality, integrations with other systems, performance, and decisions such as whether to move a site to Edge Delivery Services. Those are covered in a Blueprint.
fixed project hoursevery migration
Cloud Manager setup
24 h
Content transfer runs
40 h
Regression QA
60 h
Cutover and hypercare
40 h
Total 164 h, added to the hours from your findings

Questions

Common questions

What files can I scan?

The results.csv exported from Adobe's Best Practices Analyzer, or a .zip of your AEM project (core, ui.apps, ui.config, dispatcher). Archives up to 250 MB are supported.

Is my code uploaded?

No. Files are read by JavaScript in your browser tab. If you click the AI summary button, only aggregated finding types and counts are sent to our server, where our own AI model writes the summary (Anthropic's Claude is the fallback). File contents and paths are never sent.

How accurate is the estimate?

It is a planning estimate based on published Adobe patterns and per-finding effort heuristics shown below. A Blueprint replaces it with a fixed-scope plan after we inspect the full estate.