{"id":237317,"date":"2026-02-18T08:31:52","date_gmt":"2026-02-18T08:31:52","guid":{"rendered":"https:\/\/osmosys.co\/ca\/?p=237317"},"modified":"2026-02-18T08:31:56","modified_gmt":"2026-02-18T08:31:56","slug":"legacy-to-cloud-application-modernization-azure","status":"publish","type":"post","link":"https:\/\/osmosys.co\/ca\/legacy-to-cloud-application-modernization-azure\/","title":{"rendered":"Azure, from Legacy to Cloud: Choosing the Right Path for Application Modernization"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div>\n<p>You\u2019re staring at a legacy application that still runs the business\u2026 and still makes every change feel risky.<\/p>\n\n\n\n<p>The question usually lands as: <strong>\u201cDo we lift-and-shift it, or rebuild it?\u201d<\/strong><br>But the real question is: <strong>what outcome do we need, and what risk can we carry while we get there?<\/strong><\/p>\n\n\n\n<p>Moving an app to <strong>Azure<\/strong> can be a solid first step. It can also be an expensive way to keep the same problems, if you don\u2019t make conscious choices about architecture, delivery, security, and operations.<\/p>\n\n\n\n<p>This guide gives you a decision framework you can use with your team to choose the right modernization path, avoid common pitfalls, and measure progress in a way that matters to ANZ, US, and Canada stakeholders.<\/p>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2>Table of Contents<\/h2><nav><ul><li><a href=\"#1-cloud-migration-vs-modernization-what-changes-and-what-doesnt\">Cloud migration vs modernization: what changes (and what doesn\u2019t)<\/a><\/li><li><a href=\"#2-the-modernization-options-the-paths-teams-actually-take\">The modernization options: the paths teams actually take<\/a><ul><\/ul><\/li><li><a href=\"#3-the-decision-framework-business-value-vs-complexity\">The decision framework: business value vs. complexity<\/a><ul><\/ul><\/li><li><a href=\"#4-planning-your-path-with-microsoft-cloud-adoption-framework\">Planning your path with Microsoft Cloud Adoption Framework<\/a><ul><\/ul><\/li><li><a href=\"#5-tooling-support-azure-migrate-azure-accelerate\">Tooling support: Azure Migrate + Azure Accelerate<\/a><ul><\/ul><\/li><li><a href=\"#6-risk-mitigation-how-teams-avoid-disruption\">Risk mitigation: how teams avoid disruption<\/a><ul><\/ul><\/li><li><a href=\"#7-region-lens-anz-us-canada-considerations-high-level\">Region lens: ANZ, US, Canada considerations (high-level)<\/a><ul><\/ul><\/li><li><a href=\"#8-success-metrics-that-prove-progress-without-vanity-numbers\">Success metrics that prove progress (without vanity numbers)<\/a><ul><\/ul><\/li><li><a href=\"#9-implementation-checklist-use-this-before-you-commit\">9) Implementation checklist (use this before you commit)<\/a><\/li><li><a href=\"#the-right-path-is-the-one-you-can-execute-safely\">The \u201cright\u201d path is the one you can execute safely<\/a><\/li><li><a href=\"#request-a-legacy-app-assessment\">Request a Legacy App Assessment<\/a><\/li><\/ul><\/nav><\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"1-cloud-migration-vs-modernization-what-changes-and-what-doesnt\">1) Cloud migration vs modernization: what changes (and what doesn\u2019t)<\/h2>\n\n\n\n<p><strong>Cloud migration<\/strong> is about <em>where<\/em> the workload runs.<br><strong>Modernization<\/strong> is about <em>how<\/em> the workload behaves, reliability, security posture, maintainability, scalability patterns, and deployment discipline.<\/p>\n\n\n\n<p>A common failure mode is treating infrastructure change as the finish line. The app runs in the cloud, but:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>releases are still painful<\/li>\n\n\n\n<li>outages still take too long to diagnose<\/li>\n\n\n\n<li>dependencies are still unclear<\/li>\n\n\n\n<li>security and access controls are still inconsistent<\/li>\n\n\n\n<li>the data layer is still brittle<\/li>\n<\/ul>\n\n\n\n<p>So before you pick an approach, align on this: <strong>what \u201cbetter\u201d means for your business.<\/strong><br>Not \u201ccloud-native\u201d as a label, <strong>better outcomes<\/strong>: fewer incidents, faster change, clearer governance, reduced operational burden, and predictable performance.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"2-the-modernization-options-the-paths-teams-actually-take\">2) The modernization options: the paths teams actually take<\/h2>\n\n\n\n<p>Microsoft\u2019s Cloud Adoption Framework describes a set of migration strategies you can apply per workload (not one-size-fits-all across the portfolio).<\/p>\n\n\n\n<p>Here\u2019s a practical breakdown you can share with stakeholders.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"modernization-strategies\">Modernization strategies<\/h3>\n\n\n\n<figure class=\"wp-block-image size-full\"><img decoding=\"async\" data-src=\"https:\/\/osmosys.co\/wp-content\/uploads\/2026\/02\/3-2.png\" alt=\"Table comparing application modernization strategies\u2014retain, retire, rehost, replatform, refactor, rearchitect, rebuild, replace\u2014with when to use each and key risks.\" class=\"wp-image-239695 lazyload\" src=\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" \/><\/figure>\n\n\n\n<p>If you want a simple mental model:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Rehost\/Replatform<\/strong> = speed and risk control (often \u201cphase 1\u201d)<\/li>\n\n\n\n<li><strong>Refactor\/Rearchitect\/Rebuild<\/strong> = long-term product health (\u201cphase 2\/3\u201d)<\/li>\n\n\n\n<li><strong>Retire\/Replace<\/strong> = portfolio clean-up and simplification<\/li>\n<\/ul>\n\n\n\n<p>Microsoft also documents the \u201c6 Rs\u201d model for modernization planning, which many teams use for portfolio decisions.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"3-the-decision-framework-business-value-vs-complexity\">3) The decision framework: business value vs. complexity<\/h2>\n\n\n\n<p>If teams argue about \u201clift-and-shift vs rebuild\u201d for weeks, it usually means they\u2019re missing a shared decision frame.<\/p>\n\n\n\n<p>Use a <strong>2\u00d72<\/strong>: <strong>Business Value<\/strong> vs <strong>Modernization Complexity<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"step-1-score-each-app-fast-not-perfect\">Step 1: Score each app (fast, not perfect)<\/h3>\n\n\n\n<p>Ask four questions:<\/p>\n\n\n\n<p><strong>Business value<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Is this app strategic to revenue, customer experience, or operations?<\/li>\n\n\n\n<li>Is it differentiating, or could it be replaced without losing edge?<\/li>\n<\/ul>\n\n\n\n<p><strong>Complexity \/ risk<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>How tangled are dependencies (auth, data, integrations, batch jobs)?<\/li>\n\n\n\n<li>How fragile is release\/testing today?<\/li>\n\n\n\n<li>How much domain logic lives in the app vs surrounding systems?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"step-2-map-it-to-a-path\">Step 2: Map it to a path<\/h3>\n\n\n\n<p><strong>High value + low complexity<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Good candidate for <strong>replatform<\/strong> or targeted <strong>refactor<\/strong><\/li>\n\n\n\n<li>Aim: faster change and reduced operational burden<\/li>\n<\/ul>\n\n\n\n<p><strong>High value + high complexity<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat as a <strong>phased modernization<\/strong> program<\/li>\n\n\n\n<li>Often: <strong>strangler pattern<\/strong> (incrementally replace components), plus strong <a href=\"https:\/\/osmosys.co\/blog\/devops-agentic-ai-enterprise-development\/\">DevOps foundations<\/a><\/li>\n\n\n\n<li>Avoid \u201cbig bang\u201d rewrites unless you have unusual certainty<\/li>\n<\/ul>\n\n\n\n<p><strong>Low value + low complexity<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Consider <strong>replace<\/strong> (SaaS) or <strong>retire<\/strong><\/li>\n\n\n\n<li>Aim: remove maintenance load and reduce portfolio sprawl<\/li>\n<\/ul>\n\n\n\n<p><strong>Low value + high complexity<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Usually <strong>retain<\/strong> temporarily while you isolate dependencies<\/li>\n\n\n\n<li>Or <strong>retire<\/strong> once data and downstream usage are understood<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"what-this-prevents\">What this prevents<\/h3>\n\n\n\n<p>It prevents teams from defaulting to architecture preferences (\u201cwe should microservice everything\u201d) and forces a business-aligned decision: <strong>what do we keep, what do we change, what do we remove.<\/strong><\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"4-planning-your-path-with-microsoft-cloud-adoption-framework\">4) Planning your path with Microsoft Cloud Adoption Framework<\/h2>\n\n\n\n<p>Good modernization doesn\u2019t start with a migration tool. It starts with <strong>portfolio clarity<\/strong> and <strong>delivery realism<\/strong>.<\/p>\n\n\n\n<p>Microsoft\u2019s Cloud Adoption Framework (CAF) is useful here because it breaks migration planning into decisions most teams overlook until late: strategy selection, readiness, landing zone foundations, governance, and operations.<\/p>\n\n\n\n<p>A practical sequence that works well:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"1-inventory-and-dependency-mapping\">1) Inventory and dependency mapping<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identify apps, databases, integrations, identity flows, and \u201cquiet\u201d dependencies (batch jobs, email, file drops)<\/li>\n\n\n\n<li>Classify workloads using the strategies above (per workload, not per program)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"2-define-your-target-operating-model-before-the-move\">2) Define your target operating model (before the move)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Who owns what in production?<\/li>\n\n\n\n<li>What is your incident response flow?<\/li>\n\n\n\n<li>What does \u201chealthy\u201d look like for each critical workflow?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"3-build-a-landing-zone-and-guardrails\">3) Build a landing zone and guardrails<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity, network boundaries, logging\/monitoring, key management<\/li>\n\n\n\n<li>Governance that matches risk (not paperwork theatre)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"4-execute-in-waves\">4) Execute in waves<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Low-risk wins first (prove the approach)<\/li>\n\n\n\n<li>Then business-critical workloads with lessons learned built-in<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"5-tooling-support-azure-migrate-azure-accelerate\">5) Tooling support: Azure Migrate + Azure Accelerate<\/h2>\n\n\n\n<p>Tooling won\u2019t make decisions for you, but it can reduce manual effort and improve visibility.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"azure-migrate-and-ai-assisted-planning\">Azure Migrate (and AI-assisted planning)<\/h3>\n\n\n\n<figure class=\"wp-block-image size-full\"><img decoding=\"async\" data-src=\"https:\/\/osmosys.co\/wp-content\/uploads\/2026\/02\/2-2.png\" alt=\"Decision tree showing how to choose an application modernization approach on Azure based on business value and technical complexity.\" class=\"wp-image-239694 lazyload\" src=\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" \/><\/figure>\n\n\n\n<p>Azure Migrate supports discovery, assessment, and migration planning across workloads, and Microsoft has been adding AI-assisted capabilities to reduce friction in migration and modernization programs.<\/p>\n\n\n\n<p>Use it to:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>build an inventory and map dependencies<\/li>\n\n\n\n<li>group workloads into \u201cwaves\u201d<\/li>\n\n\n\n<li>document readiness and risks in a structured way<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"azure-accelerate\">Azure Accelerate<\/h3>\n\n\n\n<p>Azure Accelerate is Microsoft\u2019s umbrella program that brings together prior offerings (including Azure Migrate and Modernize \/ Azure Innovate) and pairs partners and customers with guidance and investment support for cloud and AI initiatives.<\/p>\n\n\n\n<p>If your organization is unsure where to start, this kind of structure matters: it pushes the program away from \u201cad-hoc migrations\u201d and toward repeatable execution.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"6-risk-mitigation-how-teams-avoid-disruption\">6) Risk mitigation: how teams avoid disruption<\/h2>\n\n\n\n<p>Modernization fails most often in the \u201cin-between\u201d phase, when the old and new worlds must coexist.<\/p>\n\n\n\n<p>Here\u2019s what reduces risk in practice:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"staged-cutovers-and-rollback-clarity\">Staged cutovers and rollback clarity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Decide up front: what triggers rollback, who approves it, and how it\u2019s executed<\/li>\n\n\n\n<li>Don\u2019t rely on \u201cwe\u2019ll figure it out if something breaks\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"testing-that-matches-reality\">Testing that matches reality<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Regression tests for critical business flows (not just unit tests)<\/li>\n\n\n\n<li>Integration tests for identity + data + external services<\/li>\n\n\n\n<li>Performance testing for peak patterns, not average load<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"data-migration-as-a-program-not-a-task\">Data migration as a program, not a task<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define data ownership, quality checks, and reconciliation approach<\/li>\n\n\n\n<li>Plan for dual-write or sync if you\u2019re moving in phases<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"delivery-discipline-the-hidden-multiplier\">Delivery discipline (the \u201chidden multiplier\u201d)<\/h3>\n\n\n\n<p>Modernization becomes safer when your release model is predictable: small changes, clear approvals, traceability, and monitoring that connects incidents to changes.<\/p>\n\n\n\n<p>If you want a practical blueprint for modern delivery on Microsoft programs, this Osmosys post is a useful companion:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Agile, DevOps, and Beyond: Modern Delivery Approaches for Microsoft Projects<\/strong><\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"7-region-lens-anz-us-canada-considerations-high-level\">7) Region lens: ANZ, US, Canada considerations (high-level)<\/h2>\n\n\n\n<p>This is not legal advice, treat this as planning input and validate with your compliance and legal teams.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"anz-australia-new-zealand\">ANZ (Australia \/ New Zealand)<\/h3>\n\n\n\n<p>If you handle personal information, privacy expectations and governance requirements should be treated as design inputs. Australia\u2019s <strong>Privacy Act<\/strong> is the baseline framework for many organizations\u2019 handling of personal information.<br>For cloud initiatives, organizations often benefit from privacy impact assessment practices, especially for systems that touch customers, employees, or citizens.<\/p>\n\n\n\n<p><strong>Local proof point:<\/strong> Christchurch City Council has publicly discussed migrating a large share of its server estate to Microsoft\u2019s cloud, framing it as a foundation for modern analytics and AI capabilities.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"canada\">Canada<\/h3>\n\n\n\n<p>Canada\u2019s federal private-sector privacy law <strong>PIPEDA<\/strong> applies to many organizations collecting, using, or disclosing personal information in commercial activities.<br>Modernization programs that involve customer data, call centers, or employee data should plan early for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>access controls and auditability<\/li>\n\n\n\n<li>retention and deletion expectations<\/li>\n\n\n\n<li>incident response readiness<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"united-states\">United States<\/h3>\n\n\n\n<p>The US context is often <strong>sector-driven<\/strong> (regulated industries set expectations on security controls, auditability, and third-party risk). Even when a formal standard isn\u2019t mandated, cloud security reviews tend to expect:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>clear identity boundaries<\/li>\n\n\n\n<li>logging\/monitoring readiness<\/li>\n\n\n\n<li>least-privilege access patterns<\/li>\n\n\n\n<li>vendor and integration governance<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"8-success-metrics-that-prove-progress-without-vanity-numbers\">8) Success metrics that prove progress (without vanity numbers)<\/h2>\n\n\n\n<p>Avoid measuring modernization by \u201capps moved.\u201d That\u2019s activity, not outcome.<\/p>\n\n\n\n<p>Use signals that executives and delivery teams both care about:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"delivery-and-change-safety\">Delivery and change safety<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Are releases becoming smaller and more predictable?<\/li>\n\n\n\n<li>Are rollbacks rarer and easier?<\/li>\n\n\n\n<li>Are deployment approvals traceable and consistent?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"operational-reliability\">Operational reliability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Faster incident detection and clearer root cause<\/li>\n\n\n\n<li>Reduced repeat incidents tied to the same failure modes<\/li>\n\n\n\n<li>Monitoring coverage of critical user journeys (not just CPU graphs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"platform-and-security-posture\">Platform and security posture<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity and access controls are consistent across workloads<\/li>\n\n\n\n<li>Audit logs and retention policies are defined and tested<\/li>\n\n\n\n<li>Third-party integrations have clear ownership and review cadence<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"business-experience\">Business experience<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Users trust the system changes (less \u201crelease fear\u201d)<\/li>\n\n\n\n<li>Performance complaints reduce for critical workflows<\/li>\n\n\n\n<li>Cross-region experience is consistent (ANZ\/US\/CA rollouts)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"9-implementation-checklist-use-this-before-you-commit\">9) Implementation checklist (use this before you commit)<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Confirm what \u201cbetter\u201d means (reliability, speed of change, cost predictability, security posture)<\/li>\n\n\n\n<li>Inventory workloads and dependencies (including batch jobs and integrations)<\/li>\n\n\n\n<li>Classify each app using migration strategies (retain\/retire\/rehost\/replatform\/refactor\/rearchitect\/rebuild\/replace)<\/li>\n\n\n\n<li>Build a value vs complexity view to prioritize sequencing<\/li>\n\n\n\n<li>Define landing zone foundations: identity, network boundaries, logging, secrets\/key management<\/li>\n\n\n\n<li>Decide operating model: ownership, on-call, incident response, change approvals<\/li>\n\n\n\n<li>Choose your wave plan (start with low-risk wins, then scale)<\/li>\n\n\n\n<li>Define cutover and rollback criteria per critical workload<\/li>\n\n\n\n<li>Build testing coverage for business-critical workflows (not just components)<\/li>\n\n\n\n<li>Plan data migration and reconciliation approach for phased moves<\/li>\n\n\n\n<li>Set \u201csuccess signals\u201d and review cadence (monthly is usually practical)<\/li>\n\n\n\n<li>Document region requirements (ANZ\/US\/CA) as design constraints, not afterthoughts<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"the-right-path-is-the-one-you-can-execute-safely\">The \u201cright\u201d path is the one you can execute safely<\/h2>\n\n\n\n<p>There\u2019s no universal best answer. The right approach depends on your constraints: budget, skills, risk tolerance, timelines, and how critical the system is.<\/p>\n\n\n\n<p>What matters is making the decision explicitly, with a framework, and building the foundations that keep modernization from becoming disruption.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><a href=\"https:\/\/osmosys.co\/book-a-demo-2\/\"><img decoding=\"async\" data-src=\"https:\/\/osmosys.co\/wp-content\/uploads\/2026\/02\/4.png\" alt=\"Modernization checklist for planning an Azure migration, including dependency mapping, landing zone setup, testing, cutover planning, and success metrics.\" class=\"wp-image-239696 lazyload\" src=\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" \/><\/a><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"request-a-legacy-app-assessment\">Request a Legacy App Assessment<\/h2>\n\n\n\n<p>If you\u2019re deciding between rehosting, refactoring, rebuilding, or replacing, <strong>Osmosys can assess one legacy application and produce a practical modernization roadmap<\/strong>, including recommended path, sequencing, risk points, and the delivery steps required to execute it.<\/p>\n\n\n\n<p><strong>Request a Legacy App Assessment<\/strong> (and get a roadmap you can take to stakeholders).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>You\u2019re staring at a legacy application that still runs the business\u2026 and still makes every change feel risky. The question usually lands as: \u201cDo we lift-and-shift it, or rebuild it?\u201dBut the real question is: what outcome do we need, and what risk can we carry while we get there? Moving an app to Azure can [&hellip;]<\/p>\n","protected":false},"author":44,"featured_media":237318,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"off","_et_pb_old_content":"","_et_gb_content_width":"","_lmt_disableupdate":"","_lmt_disable":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[136],"tags":[141,169,174],"class_list":["post-237317","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","tag-azure","tag-azure-devops","tag-cloud-migration"],"modified_by":"mounika","jetpack_featured_media_url":"https:\/\/osmosys.co\/ca\/wp-content\/uploads\/sites\/5\/2026\/02\/1-2.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/posts\/237317","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/users\/44"}],"replies":[{"embeddable":true,"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/comments?post=237317"}],"version-history":[{"count":3,"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/posts\/237317\/revisions"}],"predecessor-version":[{"id":237321,"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/posts\/237317\/revisions\/237321"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/media\/237318"}],"wp:attachment":[{"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/media?parent=237317"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/categories?post=237317"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/osmosys.co\/ca\/wp-json\/wp\/v2\/tags?post=237317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}