Elm 1.0 semantic versioning boundary: migrating a 0.19 codebase without breaking package resolution

Elm 1.0 (December 2018) introduced strict semantic versioning for published packages, but the documented compatibility boundary with 0.19 is sharp: code written for 0.19 generally fails to compile under 1.0 because of changes in the HTML renderer, the signal architecture, and the Task/Cmd/Sub type aliases.

The goal is a controlled migration of an existing 0.19 application to 1.0 while keeping dependency resolution predictable. The Elm package manager checks the installed compiler version against each dependency's declared elm-version range in its elm.json and rejects installs outside that range, so a compiler bump alone can make the whole dependency set unresolvable even before source-level API issues appear.

The uncertainty is sequencing: whether to pin and upgrade dependencies first, or migrate source code first, given that some 0.19-era packages may never have published a 1.0-compatible release. There is also no documented automated codemod covering all breaking changes, so the scope of manual edits is unclear.

Is there a recommended order for updating elm.json ranges versus rewriting application code? How should packages with no 1.0-compatible release be handled? Can elm install errors be used to map the full incompatible set upfront?