A program lifts a brittle point-to-point integration graph into the cloud unchanged. What limitation should leaders expect?
Select an answer to reveal the explanation.
Short Explanation
Moving a tangled ball of yarn to a nicer shelf doesn’t untangle it. Lift-and-shift to the cloud changes location, not the brittle integration design—you still need real architecture work.
Full Explanation
Lifting a brittle point-to-point integration graph into the cloud unchanged relocates poor architecture rather than curing it. Leaders should expect that platform relocation alone may preserve coupling; redesign is still required to improve structure and interoperability. Cloud placement does not automatically dissolve point-to-point coupling. Lift-and-shift is not modernization by definition. Brittleness does not disappear when DNS names change. Exam caveat: cloud ≠ architecture improvement without redesign. Caveat: lift-and-shift can be a temporary risk-reduction move if paired with a sequenced refactor plan—without that plan it becomes permanent technical debt in a new data center costume. Operationally, inventory point-to-point feeds after the move, prioritize strangler refactors to shared interfaces, and report coupling metrics to leadership so “we are in the cloud” is not mistaken for “we modernized integration.” After any lift-and-shift, publish a coupling scorecard of remaining point-to-point feeds so cloud relocation is not mistaken for modernization. Budget cloud moves with a parallel interoperability redesign line item; otherwise relocation funding will exhaust before brittle feeds are addressed.