Add the dependency graph to a Kotlin K2 migration checklist

A K2 migration is usually planned around source compatibility and compiler diagnostics. Projects that generate or validate dependency wiring need another checklist: compiler plugin versions, generated sources, metadata compatibility, and graph verification on every target.

Map the toolchain first

Record the Kotlin plugin, Compose compiler plugin, KSP or annotation tooling, dependency-injection compiler plugin, Android Gradle plugin, and target libraries. Upgrade from a known matrix instead of selecting each latest version independently.

JetBrains explains that the Compose compiler now ships with Kotlin and that each module using Compose must apply the matching plugin. The current Compose compiler migration guide should be checked for the selected Kotlin version. Multiplatform compatibility rules can change, so do not keep a copied version table as permanent truth.

Clean generated output deliberately

Compiler migrations can leave stale generated files and caches. Run a clean build in CI, inspect generated-source locations, and compare the definitions before and after the migration. A local incremental build is not sufficient evidence.

Exercise graph variants

Compile all product flavors and source-set targets that supply different bindings. Run the dependency graph checks for each. Then test a small runtime slice for startup, navigation-owned objects, background work, and platform services.

Keep the rollback coherent

A rollback must restore the Kotlin plugin, Compose compiler plugin, DI compiler or annotation tooling, and generated-code configuration together. Reverting only the language version can leave an incompatible plugin in place.

The dependency graph is an output of the toolchain. Include it in migration evidence, even when application source changes are small.