The migration you keep almost-doing is not a migration.

If your team has been "planning to migrate off X" for two years without moving, the plan is not the migration. The plan is the technology of avoidance.

The hook

I pulled up the JIRA board for a platform team I advise. Filtered by label: "tech-debt." Sorted by created date. The oldest ticket was from March 2024: "Migrate off legacy Rails monolith." It had been moved to the next sprint forty-one times. Forty-one. The ticket's description had been edited fourteen times, each edit making the plan more detailed and the commitment more theoretical. Nobody had written a line of migration code.

अइकाल परी ऐसें नव्हे बाई · You Will Hear This And Still Not Leave

अइकाल परी ऐसें नव्हे बाई । न संडा या सोई भ्रतारीची ॥ १ ॥
नव्हे आराणुक लौकिकापासून । आपुल्या आपण गोविलें तें ॥ २ ॥
तुका ह्मणे मन कराल कठिण । त्या या निवडोन मजपाशीं ॥ ३ ॥
This abhanga names a specific type: the person who has heard the reasons to leave many times and still does not leave. They are not undecided. They are tied to their present life by a knot the polite conversation does not surface.

What I keep seeing

Every planning cycle, someone raises the same tech-debt item. "We should really migrate off the legacy Rails monolith." Or the shared MySQL cluster. Or the internal RPC framework nobody understands anymore. Everyone nods. It goes on the roadmap. It gets deprioritised for something urgent by week three. Next planning cycle: same item, same nod, same slippage.

Two years later, the debt is still there. The engineering leader who championed the migration has stopped championing it. They still believe it should happen. They no longer believe it will. I have been that engineering leader. The feeling is very specific: you are not wrong about the problem, but you have lost the argument so many times that raising it again feels like a personality flaw.

The mechanics

There are exactly two states a tech-debt item can be in. Either it is being actively worked on, with a specific team assigned, a specific end date, and a specific set of features that will not get built because the team is doing this instead. Or it is not being worked on. There is no third state called "we are planning to."

The planning state feels like a state because it produces artifacts: documents, RFCs, migration plans, roadmap items, hopeful Slack messages. None of these artifacts move any code. They are the visible byproducts of an activity that is not actually happening.

The reason it is not happening is not that the team is unwilling. It is that the migration would require displacing something else on the roadmap, and no one has been willing to name what that would be. This is the mechanical shape of a knot. The tech debt persists because it is tied to the roadmap by an invisible commitment: "we said we would ship X by Q3." Every planning conversation asks "are we going to fix the debt" without ever asking "are we willing to slip X to fix it," and so the answer is always technically yes and functionally no.

Where Tuka comes in

The abhanga opens with a line that describes this state with uncomfortable accuracy: अइकाल परी ऐसें नव्हे बाई / न संडा या सोई भ्रतारीची -- "you will hear all this and still not leave; you cannot detach from what you are tied to." Tuka is not being contemptuous. He is being precise. The person who has heard the reasons to leave many times and still has not left is not undecided. They are constrained by something the polite conversation will not surface.

The abhanga's next move is worth studying. Tuka does not say "try harder to leave." He says: मन कराल कठिण / त्या या निवडोन मजपाशीं -- "if you make your mind hard, I will separate you from what holds you." The way out of the knot is not to satisfy both constraints. It is to force them into the same room and choose one.

What I would actually do

Stop planning the migration. Instead, put the migration and the roadmap item it would displace into the same document, side by side, and take that document to the person who owns the delivery date. Ask them, plainly: "we can ship the roadmap item on time or we can complete the migration this year. We cannot do both. Which do you want?" Half the time they will say "ship the roadmap item," and you now have permission to formally kill the migration for the year, which is honest. A quarter of the time they will say "do the migration," and you will finally do it. The last quarter they will refuse to choose, at which point you know the migration is dead and can stop pretending otherwise. Any of those three outcomes is better than sprint forty-two of moving the same ticket.

Chetan Dhandal