woods · trywoods.ai/enterprise/migration · reviewed 20 Oct 2026
Enterprise · migrationEvery page needs a Keep, Edit or Retire.
A platform migration asks one question of every page, and most estates have never answered it because nobody reviewed the pages. woods reads the estate first and puts evidence under each answer, so the migration plan starts from a worklist rather than a reading list.
woods reads public pages only. It needs no credentials and nothing for IT to approve.
- What woods is
- woods reads the public pages of a website and reports what they contain, with the evidence for each finding. It is read-only.
- This page is for
- A content or digital team with a platform decision ahead of it, in particular estates on AEM 6.5 or Sitecore 9.x that face a migration.
- Status
- Reviewed 20 Oct 2026. Every figure carries its source, date and grade, and comes from one estate (n = 1) unless it says otherwise.
A migration forces a verdict on every page. The pages were never reviewed, so the verdict is a guess.
Years of publishing with no retire step leave an estate that no one can sort by hand. woods reads every public page it can reach and proposes one of three verdicts for each, with the evidence beside it. The proposal is the starting point of a conversation. The decision stays with your team.
The page was read, dated on evidence, and carries no open finding. It moves as it is.
Evidence: the date, and the method used to date itThe page has findings. Each shows the exact text out, the exact text in where one is known, and why.
Evidence: the finding, the rule, the pages it repeats onThe page is stale, too thin to answer a question, or reached by no link on the site.
Evidence: the age, the word count, the inbound linksBefore any migration decision, one consumer health estate already sorted itself into groups.
Source for every CF-01 figure: case file 01, one sweep of one estate, 5 Oct 2026. Grade A: our own observation. n = 1: one estate, not a sample, so read these as what a first read can find, not as a rate.
These three groups overlap, and the case file does not say by how much, so they are not added together here. Together they are the Retire and Edit conversations a migration would otherwise meet halfway through the build.
Faults look like hundreds of separate problems because one template repeats one fault on every page it renders.
The Actions surface groups findings by the rule that caused them and by the template that repeats them. One rule is one fix, applied once to the template, rather than a ticket per page. In a migration that is the difference between editing a template and editing a thousand pages.
That is a template-wide finding, and it is the kind a migration needs to know about first: content that only exists after a script runs has to be rebuilt on the new platform or it will not be found. It was measured on 38 pages, not on all 745, and the figure says so.
A lens with no coverage is refused, not reported.
When woods has read the page
- It dates the page on evidence and names the evidence.
- It lists every checkable claim in its exact words, with the page it sits on.
- It shows where two pages disagree, both versions side by side.
- The verdict on which version is current stays with you.
When it has not
- The page is marked not known. It is never scored and never padded out.
- Pages behind a sign-in are not read. woods reads public pages only.
- A comparison needs both measurements. If one was not taken, the comparison is withheld and the gap is stated.
The case file shows the rule at work: the crawl recorded no menu links on most pages, so no page was judged against the menu, and the report said that rather than reporting a gap that belonged to the crawler. Cedar compared 20,000 candidate pairs, and two statements with no wording in common would not be paired, so the 153 contradictions are a floor, not a ceiling (CF-01).
woods does not connect to AEM or Sitecore. It reads what your site publishes, as a visitor would, and it does not move, write or retire anything. Moving the content is your team’s work; woods tells you what is there to move.
Platform support dates: not yet confirmed
These rows are placeholders. Each date is grade B (a source we have read and can name, but have not re-checked) and must be confirmed against Adobe’s and Sitecore’s own lifecycle pages before this page is published. Treat nothing in this table as fact until then.
| Platform | Milestone | Date | Status |
|---|---|---|---|
| AEM 6.5 | End of support, Managed Services | 31 Aug 2026 (as recorded, grade B) | To confirm |
| AEM 6.5 | End of core support, on-premise | Feb 2027 (as recorded, grade B) | To confirm |
| Sitecore 9.x | End of support | No date stated | To confirm |
No scale figure is claimed for estates of enterprise size. What the method does guarantee is that every aggregate states its coverage denominator and what it could not read, so the size of the estate changes how long a sweep takes and never what the report is willing to say.
Put evidence under every verdict.
The Assessment reads your public pages, so it needs no credentials and no IT ticket. It returns the report: every page read, every finding with its evidence, and the template-level fixes grouped.
Questions, or a figure you want sourced: use the contact line on the team page.