Logs of Duty: Migration projects
From bold initiative to historical artifact.
Rule #1: A rewrite is a migration. Rewrites are scary. Migrations sound safer. So always label rewrite work as migration, even when you’re changing languages, data models, and mental health.
Rule #2: Don’t spend too much time planning. Let the target architecture emerge organically through half-finished diagrams. Anyway, the plan will quickly become outdated after a complete staff turnover.
Rule #3: Don’t get involved too much. Make sure to attend the first meetings to give your opinion on how things should be. But leave early enough so you don’t get assigned the implementation.
Rule #4: Run old and new systems in parallel. Forever. Dual-running builds confidence and costs. But now you can decide to migrate back as your next migration project.
Rule #5: Migrate the easy 80% first. And declare migration success. The remaining 20% that contain all the risks and the critical data can wait. That will be a problem for the future engineers who will take over.
Rule #6: Change requirements mid-migration. You don’t want to complete the work too fast. It must take at least 5 years. People must realise the pain you’ve been through so you can be celebrated.
Rule #7: Don’t pause feature development. Users don’t care about migrations. Keep shipping features to both systems and let engineers develop impressive synchronization skills between the new and old systems.
Rule #8: Let the migration own no SLOs. If the migration fails, it’s expected. If prod fails, that’s a real incident. Choose your accountability wisely.
Rule #9: Communicate progress in percentages. “About 70% done” sounds reassuring, even if you’ve been repeating the same percentage for six months.
Rule #10: Never delete the old system. Decommissioning is risky. Instead, rename it to “legacy,” keep paying for it, and let people remember the good old times. Make sure to keep the Confluence pages as well. Just for memories.