A city's legacy permitting app still requires an OS build the target cloud marketplace images no longer offer cleanly. What migration consideration does this primarily highlight?
Select an answer to reveal the explanation.
Short Explanation
Think of trying to park a classic bus in a garage built for electric vans—the vehicle still works, but the bay does not fit. If the cloud images no longer ship that OS cleanly, platform compatibility is the real blocker, not fancy networking tricks.
Full Explanation
Platform compatibility of the required OS image is a migration blocker that must be resolved before a clean landing is possible. When a legacy permitting app still needs an OS build that target cloud marketplace images no longer offer cleanly, the city must address image availability, custom image import, or an application upgrade path first. Region peering must be disabled before any guest OS can be upgraded fails as unrelated networking dogma. Object storage tiers automatically supply missing OS kernels during lift-and-shift fails conceptually; object storage does not invent guest kernels for VMs. CDN caching replaces OS image selection for stateful municipal applications fails because CDNs do not solve guest OS compatibility for compute instances. Exam caveat: migration readiness includes OS and platform compatibility alongside sizing and transfer—missing images are blockers, not footnotes. Operational check: inventory guest OS versions, check marketplace and bring-your-own-image options, test boot and agent install in a sandbox subscription, and escalate a remediation plan before civic cutover dates are locked with vendors and council. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate.