Run on top of Optimizely

SeeAMess can sit on top of a running Optimizely CMS 12 site. It reads Optimizely’s database and never writes to it. You move in three phases, and until the last one, going back means discarding the overlay: Optimizely was never changed, so there is nothing to restore.

Phase	Editors work in	SeeAMess	Going back
1. Read only	Optimizely	Syncs Optimizely’s content and serves it	Point the front-end back at Optimizely
2. Overlay	Both, page by page	Its published versions win; the rest shows through from Optimizely	Discard the overlay
3. Independence	SeeAMess	Owns all content; the adapter is off	Not after adopt

Phase 1: read only

Assess. Report Optimizely’s types, property types, volumes, and everything that would become opaque:

m="scripts/dotnet10 run --project sdk/dotnet/SeeAMess.Migration.Optimizely --"
$m assess --source "<Optimizely connection string>"

Sync. Copy Optimizely’s content into SeeAMess as upstream versions, and keep following it:
```
$m sync --source "<…>" --url http://127.0.0.1:5080 --token dev --watch 30
```
The adapter opens Optimizely’s database read-only, pushes the schema of Optimizely’s content types into a scope named after the source, and sends only what changed since the last pass. It keeps no state of its own: its position is stored in SeeAMess. A repeated batch changes nothing.
Verify. Compare both delivery APIs for the published URLs, field by field:
```
$m verify --optimizely http://localhost:5000 --seeamess http://127.0.0.1:5080
```
The expected differences are listed by the tool; everything else is a failure.
Switch the front-end. SeeAMess answers in the shape of Optimizely’s Content Delivery API v3, including integer IDs, so a headless front-end changes one base URL:
```
CMS_URL=http://127.0.0.1:5080 pnpm -C web dev
```

Editors keep working in Optimizely. Their changes appear in SeeAMess after the next sync.

Phase 2: the editorial overlay

Editors start working in SeeAMess. Their versions are stored in SeeAMess’s own tables, on top of the upstream ones.

Following (the default): a content and locale shows whatever Optimizely has published. Sync moves the pointer.
Forked: once a version is published in SeeAMess, that content and locale is forked. Sync still records new upstream versions, but no longer changes what is live, and marks the content upstream changed when Optimizely moves on. Saving a draft does not fork.
Structure: parent, order and deletion follow Optimizely until the content is moved or deleted in SeeAMess.
New content created in SeeAMess is native from the start, even below an upstream parent.

Upstream versions are immutable: a draft based on one is a new native version, and the database itself refuses to change an upstream version outside a sync.

In the editor:

Publishing content that follows Optimizely shows a one-time notice that the page will stop following it.
Forked content shows a badge. If Optimizely changed afterwards, the badge offers a comparison with the upstream version and two actions: accept upstream or keep the overlay.
The Overlay screen lists everything forked, which is also the list of what a rollback would discard.

The overlay compare dialog: the upstream version of a summary field beside the SeeAMess version, with the changed words marked.

The same actions are on the API:

Request	Effect
`GET /authoring/v1/overlay?state=forked`	What is forked (also `upstreamChanged`, `structureForked`)
`POST /authoring/v1/content/{id}/overlay/accept-upstream?locale=`	Keep the native history, go back to following the source
`POST /authoring/v1/content/{id}/overlay/discard?locale=`	Delete the native versions, go back to the source. Without `locale`, also restores the structure.

Phase 3: independence

One command adopts all upstream content, versions and types as native ones:

curl -X POST -H 'Authorization: Bearer dev' \
  http://127.0.0.1:5080/authoring/v1/sources/optimizely/adopt

Nothing visible changes, so nothing is re-projected: measured, every delivery response is byte-identical to before. Integer IDs are kept, so the compatibility API keeps answering with them. Sync is refused from then on, and Optimizely can be retired.

Limits

Changes made in SeeAMess are not visible in Optimizely. The Optimizely editor and anything reading Optimizely directly see the old content.
Two editors can change the same page in two systems during the overlay. The fork rule makes the outcome predictable (SeeAMess wins once it has published) and the mark makes it visible. It does not merge.
Types in a source scope cannot be changed in SeeAMess until adopt.
Access rights are copied at sync.
Change detection reads a small fingerprint of every content on each pass: fine up to some hundreds of thousands of contents. Measured: 20,000 contents with 42,000 versions sync in 40 s the first time, and a repeat sync with nothing changed takes 8 s.