TechGrit approached this as a compound engineering problem: the migration itself, the AI tooling strategy, and the sequencing plan all had to be solved simultaneously. The approach rested on four deliberate moves. 

Move 1: Build a Migration Skill, Not a Migration Script 

The first decision was the most consequential. Rather than writing one-off migration scripts, TechGrit built on an existing dotnet-migration-skill, a structured AI playbook checked into the repository alongside the code, that Claude follows phase by phase. The skill was not run cold on the live codebase. Before invoking it, a human engineer audited the full Paket dependency graph, mapped which packages were net48-only and would need net10 replacements, and sketched the Directory.Packages.props structure. Only after that groundwork was done did the skill execute the mechanical bulk of the conversion. The skill ran three full iterations on Dex. Iteration 1 produced the structural skeleton but left gaps: missing conditional ItemGroup blocks and no preprocessor directives in source files referencing legacy APIs. Iteration 2 addressed the structural gaps and surfaced that EF6, .NET Remoting, and OWIN had no .NET 10 equivalent, requiring full replacement implementations rather than stubs. Iteration 3 produced correct implementations for all three subsystems, with the wire-protocol spec, EF Core migration pattern, and Kestrel route inventory provided as explicit input. Every gap found in each pass was folded back into the skill permanently. The pattern throughout was deliberate: prepare the ground manually, direct Claude with increasing precision, review the output critically, identify gaps, and repeat until the bar was met. Three repositories in, the skill had accumulated 50+ rules. By the time the full IDE migration begins, it starts from a near-final state on every new project. 

Move 2: Sequence by Dependency, Not by Convenience

The migration order was determined entirely by the dependency graph, not by ease. Libs migrated first because Dex depended on it. Dex completed before Rox was unblocked. Rox completed before any work on the full IDE platform could begin. Within each repository, projects were ordered by batch dependency, so that each batch could be parallelized internally but every batch completed before the next began. This sequencing meant that the migration skill was applied to increasingly complex codebases in the right order, and that learnings from each stage directly benefited the next. 

Move 3: Treat Technology Replacements as First-Class Engineering Work

The migration skill automates the mechanical conversion. It does not write technology replacements. Five legacy technologies required full replacement implementations: EF6 to EF Core, .NET Remoting to Named Pipes, OWIN and NetworkComms to Kestrel, SOAP service references to HttpClient, and WiX v3 to WiX v6. Each replacement was engineered as a first-class deliverable with the same approach: enumerate the API surface, implement at exact parity with the legacy behavior, validate on both targets, and document the pattern for reuse. An audit skill was built alongside the migration skill to verify that zero stub implementations remained before any repository was declared complete. 

Move 4: Build a Dedicated Runtime Testing Phase Into Every Repository

The pilot revealed a finding that reshaped the full plan: compiler success and runtime correctness are independent. Nine runtime behavioral differences were found across Libs and Dex alone, covering SQLite locking, WPF window activation, process launching, ContextMenu teardown, MSI service installation, and configuration file compatibility. None were visible at build time. Each was diagnosed, fixed, and written back into the skill as a proactive check for all future repositories. A mandatory runtime testing phase was added to every subsequent batch to catch the same class of failure before it reached production.