Two frameworks come up constantly in application strategy: the TIME model and the 6 Rs of cloud migration. They're often confused, but they answer different questions — and work best together.
These two get compared constantly, usually by people trying to pick one. That is the wrong question, because they answer different things.
The TIME model asks: should we still have this application at all? It plots business value against technical quality and sorts everything into tolerate, invest, migrate or eliminate. It is a portfolio decision made before you know or care where anything will run.
The 6 Rs ask: given that we are keeping this application and moving it to cloud, how? Rehost, replatform, repurchase, refactor, retire, retain. It is an execution decision about migration mechanics.
One decides the fate of the portfolio; the other decides the method of the move. Running the second without the first is how organisations end up paying to migrate applications they should have switched off.
| R | What it means | Effort |
|---|---|---|
| Rehost | Lift and shift — same application, cloud infrastructure | Low |
| Replatform | Lift and reshape — e.g. move to a managed database, keep the app | Low to medium |
| Repurchase | Replace with a SaaS product | Medium — mostly process and data, not code |
| Refactor | Re-architect for cloud-native operation | High |
| Retire | Switch it off | Low to medium |
| Retain | Leave where it is, for now | None |
The natural order is TIME first, then the 6 Rs for whatever survives. TIME tells you which applications have a future. The 6 Rs tell you how to move the ones that do.
This ordering saves real money. Migration programmes that skip the portfolio question routinely rehost a third of an estate that should never have been moved — paying migration costs, cloud running costs and a decommissioning cost eighteen months later when someone finally asks why the system exists.
| TIME quadrant | Likely R | Reasoning |
|---|---|---|
| Eliminate | Retire | Do not migrate what you are switching off |
| Tolerate | Rehost or Retain | Minimum effort. It works, nobody needs more from it — do not spend refactoring budget here |
| Invest | Refactor or Replatform | Strategic systems justify cloud-native investment; this is where refactoring pays back |
| Migrate | Repurchase or Refactor | High value, poor foundations — usually a replacement decision, so consider SaaS before rebuilding |
Treat these as starting positions rather than rules. An Invest application already running well on managed infrastructure may need nothing at all, and a Tolerate application whose hosting contract is expiring may force a decision earlier than its quadrant suggests.
Two cases need judgement rather than a lookup.
High-value systems with heavy coupling. An Invest application with thirty interfaces cannot be refactored in isolation. The R has to be chosen for the cluster, not the application, and sometimes the answer is Retain until the surrounding estate moves.
Regulatory or data residency constraints. These can override the quadrant entirely. An Eliminate application may have to be Retained until a retention period expires, and a Refactor candidate may be blocked from a given region.
If you are starting a cloud programme and have not done portfolio analysis, do it before the migration wave planning rather than alongside it. It takes weeks, not months, and it typically removes 10–20% of the migration scope outright — which is the cheapest saving available in the entire programme.
See running a rationalisation with TIME for the method, and the business case guide for turning the result into funding.
The Applications Assessment & Rationalisation Toolkit scores your estate and places every app on the TIME quadrant, so your cloud migration effort goes only where it's justified.
