### Problem/Motivation Daedalus replaces the Navigation+, Layout Builder+, Edit+ and Tempstore+ projects (and the rest of the Plus Suite), and its `composer.json` conflicts with all of them: a site carries one or the other. The sites that exist run the old released lineages (`lb_plus` 3.6.x, `navigation_plus` 2.3.x, `edit_plus` 2.3.x, `tempstore_plus` 1.0.x, usually with `section_library` and the Edit+ example block modules). Those sites have no road to Daedalus today: `composer require drupal/daedalus` refuses while any old package is locked, and every Daedalus module is a new extension with a machine name Drupal has never seen, so nothing about a site's persisted state carries over by itself. This is not a normal Drupal update. An update runs the `hook_update_N` and post_update hooks of modules that are already installed. Here every module the site runs is replaced by a differently named one. Installing Daedalus fresh beside the old data would mark every Daedalus post_update as already run (core records all existing post_updates at install) and leave config, the update registries, key_value entries and every stored Layout Builder section speaking the old names. The old-lineage to 2.0 semantic migrations (layout blocks to nested sections, permission renames, section library templates to stencils) already exist in Daedalus under the new names; they just never get to run on a site whose registries do not name the renamed modules. ### Proposed resolution Ship a published, best-effort migration pathway inside the `daedalus` package, under `migrate/plus_suite/`, that a person or a coding agent runs after the composer swap: * `mapping.tsv`: the one table of old names to new names (module ids, prefixes, class names, permission strings, stored asset paths, plus `floor` rows naming the oldest schema version served per old module). The translator and the code-rename tooling read the same table. * `translate.php`: a drush script (`drush php:script`) with three phases. **audit** (read-only) reports the old modules' schema versions against the floors, every config object, key_value entry, role and stored layout section naming an old module, the heading components the content phase will rewrite, and every file under `modules/custom` and `themes/custom` that names an old module, class, JavaScript root or CSS prefix; it refuses a site below the floor or whose text formats strip the `class` attribute. **rename** installs the foundation modules, then translates `core.extension`, `system.schema`, the post_update registry, every config object, the key_value rows, the user settings column and every stored layout section by walking the values (never by substituting text inside serialized strings), and un-marks the section library migration so `updb` runs it. **content** converts the one old block type with a real counterpart: each old heading component becomes a Daedalus text block (label to `field_text_text`, size to `field_text_tag`, url when the link was enabled). * `recipe.yml`: a non-strict migration recipe for what a translated site needs and the old releases never had (daedalus_stylish with its layouts, layers and the Olivero skin, the text, image and formatted text block modules, and an active design system). It does not include the daedalus_recipe ingredients, which hard-require the AI stack and are strict on config a translated site already carries. * `migrate.sh`: the orchestrator. Dump, audit, rename, `drush updatedb` (Daedalus's own hooks do the semantic work here), the recipe or the site's exported config, content, closing audit; it stops at the first failure and names the dump and the restore command. * `MIGRATING.md`: the guide for a person (preconditions, the composer swap, the run, porting the site's own code with the same table, browser review, what does not carry over, finishing the section library retirement across environments, recovery). `PROMPT.md`: a prompt to hand a coding agent that drives the guide. * Scope: sites on the latest old releases (`lb_plus` 3.6.13, `navigation_plus` 2.3.10, `edit_plus` 2.3.4, `tempstore_plus` 1.0.5), Drupal 11.3 or later, with every old update run. Older lineages are refused by the audit rather than guessed at. Best effort: the losses are listed in the guide (heading alignment, older revisions, the call to action and teaser example block types, site-specific keys on layout blocks, prose that named the old suite, the site's own code). Proved end to end on a production site (bozeman.engineering: 8 nodes, 95 blocks, 42 sections, 4 section library templates, custom modules coupled to the Edit+ block properties event), including the second-environment leg where the run imports the first environment's exported config in place of the recipe. Two runtime changes ride along, found by the trial: `daedalus_ui`'s outbound path processor consults the router only for load-editable-page paths (it recursed on a migrated site), and `daedalus_ui_update_10403` retires the `place_block` default tool. The pathway ships from `1.0.0-alpha1` on; alpha0 has no `migrate/`. ### API changes New, additive: the `Drupal\daedalus\Migrate\PhaseInterface` and `ReportInterface` contracts (what any future migration into Daedalus implements), with the Plus Suite pathway under `Drupal\daedalus\Migrate\PlusSuite` (`Mapping`, `Audit`, `Renamer`, `HeadingToText` and their reports). Nothing existing changes signature. The two runtime changes above are behavior fixes, not API. ### Data model changes None for existing Daedalus sites. On a migrated site the pathway rewrites persisted state into Daedalus's vocabulary (extension and update registries, config, key_value, the user settings column, stored layout sections), creates text blocks in place of heading components, and the recipe adds `field_image_url` to an existing `image` block type without touching the site's own displays.