Model Deprecation Migration Cost Calculator

A model migration cost calculator estimates what it takes to move a production system off an AI model that is being retired, and — critically — whether that work fits in the time the provider has given you. Model deprecation is now a routine operational event rather than a rare disruption: providers retire older versions on published schedules, often with a few months' notice, and any team with models in production will face this repeatedly. The cost is almost never the new model's token price. It is engineering time.

The estimate decomposes into the work that actually consumes weeks. Prompt re-testing is usually the largest count: every prompt tuned against the old model's behaviour has to be re-run, compared, and often rewritten, because a newer model can be objectively better yet produce differently-shaped output that breaks downstream parsing or tone requirements. Integrations need updating where model identifiers, parameters, token limits, or response formats are wired into code. Regulated workflows carry the heaviest per-item cost, because anything that underwent formal validation — in healthcare, finance, or safety contexts — may need that validation repeated with documentation, and this is frequently the long pole that dictates the schedule. Evaluation runs add direct compute cost on top of labour. Summing labour hours at your engineer rate plus evaluation compute gives total migration cost.

The calculator then applies the constraint that matters most: it converts your available engineers and remaining weeks into capacity at roughly thirty productive hours per engineer-week, and reports whether the work fits before shutdown or by how many hours it falls short. That distinction changes the decision. A migration that fits is a planned sprint; one that does not requires adding people, cutting scope, or opening a conversation with the provider about an extension — and all three options are far cheaper to pursue early than in the final fortnight. The source research recommends inventorying prompts, evaluations, integrations, regulated workflows, and release deadlines, which is exactly the inventory this calculator prices. Two habits reduce the number permanently: keeping model identifiers in configuration rather than scattered through code, and maintaining an evaluation suite that can be re-run against a candidate model automatically. Teams with both routinely migrate in days rather than months. This estimates internal effort only and excludes any price difference between the old and new model, which should be modelled separately.