ON THIS PAGE (9 SECTIONS)
- ✓Rehosting answers where the process runs. It does not answer which write is allowed.
- ✓Stephen Orban’s 2016 description of six migration strategies treats lift-and-shift as one option among others, including replatform, refactor, retire, and retain.
- ✓Attach an AI feature only when the current application can already provide a reliable write, a permission check, and a record owner. Otherwise build that boundary first.
- ✓An unused application should be confirmed and turned off, not migrated by default.
The virtual machines are in a cloud account. The data-center contract can end. The application still exports a nightly file that someone loads by hand, still stores two copies of the customer, and still cannot tell you which write is allowed to create an order. The move did what it was asked to do. It was asked to change the address of the process, not the process.
That distinction is easy to lose because the migration is visible and the workflow is not. Months later the bill, the change queue, and the integration gaps look familiar. They should. They moved with the application.
Name the constraint before you name the strategy
Stephen Orban’s 2016 AWS essay, “6 Strategies for Migrating Applications to the Cloud,” describes six approaches he saw in large migrations, building on an earlier set of “R” labels from Gartner. Rehosting is the one he also calls lift-and-shift: move the application with minimal change so a large estate can leave its current facility. Replatforming is a small set of operational changes, such as handing a database to a managed service, without rewriting the application. Refactoring reworks the architecture because the business needs a behavior the current shape cannot provide. Repurchasing moves the job to a different product. Retiring turns off something unused. Retaining leaves an application where it is, on purpose, until there is a reason to move it.
The useful part of the essay, for this decision, is the vocabulary. The strategy follows the constraint. A cost result from someone else’s estate is not a forecast for yours, so this article does not borrow one.
Match the move to the pain
| The constraint you can point to | A fitting move | What will still be true afterward |
| The facility, the hardware, or a contract date | Rehost, and schedule a workflow review with a date | The same writes, jobs, and exports |
| Patch windows, database care, or a runtime you no longer want to operate | Replatform the piece that causes the toil | The business process, unless you also change it |
| A handoff, a missing owner, or a write that cannot be audited | Refactor the boundary, or integrate at the edge and leave the core alone | A new contract for that write. The rest of the app may stay. |
| Nobody will claim the application | Confirm it is unused, then retire it | You do not migrate a process nobody runs |
| A depreciation schedule or a recent upgrade, and no urgent pain | Retain, and write down the revisit date | The application stays, by decision rather than by inertia |
What an AI feature inherits from a rehosted system
A model wrapped around a rehosted application inherits the application’s writes. If two modules can create the same customer, the model can be pointed at either copy. If the only error handling is a person who notices a bad file in the morning, the model’s mistakes will wait for the same person. If the permission model is “anyone with the VPN,” a chat tool in front of the database widens that permission with a sentence.
Add the feature when the path it needs already exists: a single writer, a permission check you can enforce in code, and a record someone can correct. Those are the conditions in Close the Handoff Before You Add AI and AI Features Need an Owner for the Record. When they are absent, the next project is the boundary, not a chat tab on the virtual machine. Put AI on the Decision, Not in a Chat Tab explains why the tab does not create the boundary for you.
Rehost when the machine is the problem. Change the workflow when the workflow is the problem. An AI feature is not a third option that skips the choice.
Illustrative scenario: the nightly file
This scenario is illustrative. It is not a Vasiva migration, and it claims no savings.
An order system runs on a virtual machine that must leave a facility before a contract ends. Every night it drops a file that a finance analyst loads into the ledger. The exit date is real, so rehosting the virtual machine is an honest way to meet it. The nightly file is a separate constraint. Moving the machine does not give finance a validated write, and a model that “reads the file and posts the journal” would post whatever the file contains, including a partial file from a failed job.
The sequenced plan is: rehost to meet the date; keep the analyst in the loop for the file; then replace the file with a write that rejects an unbalanced batch and records who accepted an exception. The model is not on the critical path of the move. If a later step needs to classify free-text order notes, that is a draft beside the validated write, not a replacement for it.
Checklist for the migration decision
- Write the constraint in one sentence. If the sentence is about a building, a machine, or a contract, rehosting may be sufficient for now.
- List the writes, files, and manual loads that users actually depend on. Those move unchanged unless a different project changes them.
- Name any application nobody will own. Confirm it is unused before you migrate it. Retiring it is a strategy, not an oversight.
- If an AI feature is in the same program, state which write it will touch and whether that write is already validated.
- Set a revisit date for anything you retain or rehost without changing the workflow.
- Keep the AI work behind the boundary it needs. Do not use the migration deadline as the reason to skip the boundary.
Questions that usually come next
Is rehosting always the wrong first move?
No. It fits when the facility or the hardware is the constraint and the workflow can remain for a period you have dated. It is the wrong place to stop when the pain is the workflow and the plan ends at the new account.
When should an AI feature wait?
Wait when the feature needs a reliable write, a permission check, or a record owner the current application cannot provide. A conversational front end on the rehosted system does not supply those. Build the boundary, then let a model draft inside it.
Direct answers
Is rehosting always the wrong first move?
No. It fits when the facility or the hardware is the constraint and the workflow can remain for a dated period. It is the wrong place to stop when the pain is the workflow.
When should an AI feature wait until after a refactor?
Wait when the feature needs a reliable write, a permission check, or a record owner the current application cannot provide. A chat front end does not create those.
References & Prior Art
6 Strategies for Migrating Applications to the Cloud
Stephen Orban • Amazon Web Services (2016)
Barath
Product EngineerBarath builds production internal tools, double-entry financial ledgers, audit trail integrity, and supervised engineering workflows at Vasiva.
