The 7 Rs in one sentence each
The taxonomy comes from AWS's migration-strategy documentation, and Microsoft and Google use near-identical classifications. Rehost: move the application as it is to a virtual machine in the cloud. Replatform: move it with targeted adjustments, such as swapping the database for a managed service. Refactor or re-architect: change the application's architecture to take advantage of the cloud. Repurchase: replace it with a ready-made product, usually SaaS. Retire: switch off what nobody uses any more. Retain: keep it where it is, by decision. Relocate: move the whole virtualization layer without touching the applications.
It is worth fixing the vocabulary once and then using the English terms, because that is how the reader will meet them in provider material and in proposals. And it is worth noticing what the list says between the lines: two of the seven strategies — retire and retain — migrate nothing. That is intentional.
Which R fits each system an SMB actually has
PHP on cPanel or a dedicated server: rehost to a virtual machine, or replatform to managed PHP with a managed database. Upgrading the PHP version is a separate decision from the migration, and the article on the PHP2Shell flaw explains why it can no longer wait. Java on Tomcat on a dedicated box: rehost, as in the migration JBKR did to Jelastic — no rewrite, the dedicated-server cost eliminated and four consecutive projects rated 5/5 by the client. .NET Framework tied to Windows: rehost to a Windows VM first, replatform to current .NET later, module by module.
Counter Delphi with a local database: almost always retain the desktop client, with the database and the integration layer relocated or rehosted — the pattern of the Legate case, where the integration changed and the desktop stayed. And then the honest repurchase and retire cases: e-mail, payroll and scheduling rarely justify a custom system, and every old system has a module nobody has opened in three years that can simply be switched off.
Rehost is not "just copy it": what actually changes
The list of what breaks in a "simple" migration is predictable and always surprising: fixed IP addresses in third-party integrations, DNS, certificates, scheduled tasks, file paths, the outbound mail server, the server time zone and partner allow-lists still pointing at the old IP. None of it is hard; the problem is discovering it in production.
That is why the method is the same as any cutover: environment inventory, a test environment in the cloud, validated functional equivalence and a controlled switch with a rollback plan, as JBKR's cloud page describes. The part that deserves the most rehearsal is the data migration: it can be repeated on a copy as many times as needed, and it should be. And the backup, which on the dedicated server was a hope, becomes a configuration — the article on backups and ransomware covers how to test it.
Costs that appear after the migration
Cloud bills surprise people with items the proposal never showed: outbound data transfer, idle instances nobody switched off, oversized databases, snapshots that pile up, support tiers and per-request pricing on managed services. None of them is hidden — they are all on the providers' pricing pages — but none appears when "dedicated server per month" is compared with "virtual machine per month".
The rule that avoids the shock: budget alerts and a monthly review from day one, sizing for real load rather than the sales deck, and switching off what is not used. There is one more cost that never shows up on an invoice: provider lock-in. Replatform and refactor tie the application to specific services; rehost keeps the exit door open. That is an argument for starting with rehost, not an argument against the cloud.
When not migrating (retain) is the right answer
A stable system with no growth expected, a requirement to stay on premises (industrial environment, regulatory rule, latency to local equipment), or a team unfamiliar with the cloud and without a support contract. In those cases a dedicated server with tested backups, monitoring and a current version is not a problem to solve. An unsupported version, on the other hand, is — and that holds inside or outside the cloud, as the article on maintaining or modernizing explains.
Migration does not fix code. "Moving the problem to the cloud" is the most common outcome of a migration done without an assessment: the same system, with the same defects, now on a different monthly invoice. If the motivation is a defect in the system, the answer lies in the modernization paths, not in a change of address.
Refactor and the Strangler Fig pattern, only with a reason
Refactoring is the most expensive and riskiest strategy, and so it should be reserved for the module that actually blocks growth — billing, an integration, the customer registry — not the whole system. The reference pattern is the Strangler Fig described by Martin Fowler: new modules take over routes and functions one at a time while the old system keeps serving the rest, until the old one can be switched off.
The risks of that strategy — implicit rules, data equivalence, undocumented integrations — are detailed in the article on the risks of modernizing; the definitions of each path are in the article on what modernization is. The point here is a single one: refactoring is a precision tool, not the default plan.
How JBKR runs a migration, and the next step
Four steps, the same ones on the cloud and infrastructure page: inventory of servers, systems and databases; a strategy chosen for each piece (rehost, targeted adjustments or modernization); execution with a test environment; and a controlled switch with a rollback plan. The written result says which R applies to each component and, just as important, what it will cost to run — not only to move.
At JBKR the initial 30-minute assessment is free. The first question is not "which provider" but "what do you expect to improve after the migration" — because if the answer is "the system", the right conversation is a different one.
