Lift-and-shift is a decision, not a default
Cloud migration advice tends to come in two flavors: always refactor, or just move it. Both are wrong often enough that the choice deserves a real analysis.
Healthcare runs on systems that are older than many of the people maintaining them: survey and data-collection platforms, departmental applications, directory services and the integration engines that hold everything together. When the mandate to move to the cloud arrives, these systems force a question that is easy to answer badly. Refactoring everything is expensive and slow, and some of these platforms cannot be refactored without being replaced. Moving everything as-is is fast, and some of these platforms will cost more to run in the cloud than they did on the floor.
The honest answer is that lift-and-shift is sometimes exactly right, and the organizations that get it right are the ones that treat it as a decision with evidence behind it rather than a default. The evidence is specific. What are the licensing and support constraints of the legacy platform, and does the vendor even support the target environment? What are the dependencies, including the ones nobody has documented? What is the system's remaining life, given the business change coming toward it? What will it cost to run as-is, and what does the organization actually gain from refactoring beyond a cleaner diagram?
When moving as-is is the right call
Lift-and-shift is often correct when the platform is stable, the business process it supports is about to change in ways that will reshape the system anyway, and the goal of the migration is to exit a data center or a contract on a date. In that case, moving the system intact de-risks the deadline and defers the redesign until the business change is understood. Refactoring first would mean redesigning for a process that is about to be replaced.
When it is not
It is usually wrong when the platform's cost structure is tied to hardware that the cloud prices differently, when the system's problems are architectural rather than infrastructural, or when the migration is the only funded opportunity to fix something the organization will otherwise live with for another decade.
Either way, the analysis belongs in a document the organization keeps: the constraints, the options, the decision and the reasoning. Migrations are judged for years. The record of why is what makes the judgment fair.