{"id":3023,"date":"2026-10-08T12:09:15","date_gmt":"2026-10-08T12:09:15","guid":{"rendered":"https:\/\/www.examtopics.biz\/blog\/microsoft-az-305-azure-migration-paths-rehost-refactor-replace\/"},"modified":"2026-10-16T20:59:41","modified_gmt":"2026-10-16T20:59:41","slug":"microsoft-az-305-azure-migration-paths-rehost-refactor-replace","status":"publish","type":"post","link":"https:\/\/www.examtopics.biz\/blog\/microsoft-az-305-azure-migration-paths-rehost-refactor-replace\/","title":{"rendered":"Microsoft AZ-305: Azure Migration Paths: Rehost, Refactor, or Replace"},"content":{"rendered":"<p>Azure migration decisions are not simply choices between \u201cmove the server\u201d and \u201crewrite the application.\u201d A workload can be rehosted, replatformed, refactored, rearchitected, or replaced, and different components of the same system can follow different paths.<\/p>\n<p>For AZ-305, the architectural skill is to match the migration approach to business urgency, technical debt, application constraints, operational goals, and acceptable change risk. Microsoft\u2019s current Cloud Adoption Framework emphasizes that modernization strategies lie on a continuum: moving to a managed platform can reduce operational burden with limited code change, while deeper refactoring or rearchitecture can unlock more cloud-native behavior at the cost of greater development and testing effort. In <a href=\"https:\/\/www.examtopics.biz\/az-305\">AZ-305 architecture practice<\/a>, the decision is not simply \u201cmove to Azure\u201d: the design must explain which application dependencies survive a rehost and which justify refactoring.<\/p>\n<p>The best migration plan therefore begins with the workload\u2019s constraints and desired future state rather than with a preferred Azure service.<\/p>\n<h2>Assess the workload before choosing a migration label<\/h2>\n<p>Migration strategy should be based on evidence about the current system.<\/p>\n<p>A useful assessment covers:<\/p>\n<ul>\n<li>operating-system and runtime support<\/li>\n<li>application dependencies<\/li>\n<li>database engines and versions<\/li>\n<li>network and identity assumptions<\/li>\n<li>latency sensitivity<\/li>\n<li>licensing constraints<\/li>\n<li>peak and average utilization<\/li>\n<li>availability requirements<\/li>\n<li>deployment frequency<\/li>\n<li>technical debt<\/li>\n<li>regulatory or data-residency requirements<\/li>\n<li>business deadlines<\/li>\n<\/ul>\n<p>The same application can look very different once these constraints are visible. A stable line-of-business system with a hard datacenter-exit date may favor minimal change. A customer-facing platform that already suffers from scaling and release bottlenecks may justify more modernization during migration.<\/p>\n<p>Dependency discovery should include more than documented application diagrams. Capture actual network flows, scheduled jobs, file shares, service accounts, certificate dependencies, DNS names, licensing servers, integration endpoints, and operational scripts. Hidden dependencies are a common reason a technically successful server migration still causes an application outage. The migration wave should group systems that need to move together or deliberately preserve the cross-environment connection during the transition.<\/p>\n<p>The <a href=\"https:\/\/www.examtopics.biz\/blog\/public-private-hybrid-community-cloud-deployment-models-explained\/\">cloud deployment model<\/a> also matters when the target cannot be entirely public cloud. Regulatory, latency, or hardware dependencies can leave part of the solution on-premises and create a long-term hybrid architecture rather than a one-time transition state.<\/p>\n<h2>Rehost when speed and compatibility dominate<\/h2>\n<p>Rehosting moves a workload with minimal application change, often from an existing VM environment to Azure virtual machines.<\/p>\n<p>This approach is attractive when:<\/p>\n<ul>\n<li>a datacenter exit has a fixed deadline<\/li>\n<li>the application is difficult or risky to modify<\/li>\n<li>vendor support depends on a specific operating system or installation model<\/li>\n<li>the organization wants to separate migration from later modernization<\/li>\n<li>testing capacity for code change is limited<\/li>\n<\/ul>\n<p>Rehosting can reduce physical infrastructure responsibility quickly, but it does not automatically remove the operational characteristics of the original system. The team may still manage guest operating systems, patching, middleware, backups, scaling logic, and application deployment much as it did before.<\/p>\n<p>Architects should therefore avoid presenting rehost as the final cloud optimization state by default. It can be a deliberate first stage when speed matters, followed by later replatforming or refactoring once the workload is stable in Azure.<\/p>\n<h2>Replatform to reduce operations without rewriting the application<\/h2>\n<p>Replatforming moves components to more managed Azure services while preserving most application behavior.<\/p>\n<p>Examples can include moving a self-managed database to a managed database offering, moving web workloads from VMs to a managed application platform, or replacing a self-hosted cache with a managed service.<\/p>\n<p>The value is operational: the team gives Azure more responsibility for infrastructure maintenance, availability, backups, patching, or scaling while limiting code change.<\/p>\n<p>Replatforming is a good fit when the current application works but the infrastructure around it consumes too much operational effort. It can also provide reliability benefits because managed services often expose built-in redundancy and monitoring options that would require custom engineering in a VM-based design.<\/p>\n<p>The tradeoff is platform dependency. Managed services have supported versions, networking models, quotas, feature differences, and migration constraints. Compatibility testing remains necessary even when code changes are small.<\/p>\n<h2>Refactor when code quality or cloud fit is the limiting factor<\/h2>\n<p>Refactoring changes application code or internal structure while preserving the application\u2019s core business behavior.<\/p>\n<p>Reasons to refactor include:<\/p>\n<ul>\n<li>technical debt slows feature delivery<\/li>\n<li>the application cannot scale efficiently in its current form<\/li>\n<li>configuration and secrets are tightly coupled to the runtime<\/li>\n<li>observability is insufficient<\/li>\n<li>deployment processes are fragile<\/li>\n<li>the code assumes local state or fixed infrastructure<\/li>\n<\/ul>\n<p>Refactoring can make the application better suited to managed identity, infrastructure as code, modern telemetry, autoscaling, or managed data services without requiring a complete architectural redesign.<\/p>\n<p>This approach requires strong automated testing because code is changing even when the business functionality is not. The migration plan should budget for regression testing, performance validation, rollback, and deployment automation rather than treating refactoring as a \u201csmall cloud adjustment.\u201d<\/p>\n<h2>Rearchitect when the existing design blocks required outcomes<\/h2>\n<p>Rearchitecture changes the system\u2019s structural design. It may introduce microservices, event-driven components, serverless execution, partitioned data models, asynchronous workflows, or multi-region patterns.<\/p>\n<p>This is justified when the existing architecture cannot meet important goals such as:<\/p>\n<ul>\n<li>independent scaling of major components<\/li>\n<li>higher deployment frequency<\/li>\n<li>geographic resilience<\/li>\n<li>fault isolation<\/li>\n<li>event-driven integration<\/li>\n<li>reduced coupling between teams<\/li>\n<\/ul>\n<p>Rearchitecture can deliver substantial long-term benefits, but it has a larger failure surface during migration. New service boundaries, data flows, operational tooling, and ownership models must all be validated.<\/p>\n<p>Architects should also resist \u201cmicroservices by default.\u201d A well-structured modular application can be easier to operate than dozens of distributed services if the business does not need independent scaling or team autonomy. Modernization should solve a concrete constraint, not imitate a fashionable reference architecture.<\/p>\n<h2>Replace when the capability is more valuable than the existing implementation<\/h2>\n<p>Replacement means retiring the current application or component and adopting another product, SaaS platform, or newly built capability.<\/p>\n<p>This can be the right decision when:<\/p>\n<ul>\n<li>the existing application is no longer strategically differentiating<\/li>\n<li>vendor support has ended<\/li>\n<li>customization has created excessive maintenance cost<\/li>\n<li>a SaaS or packaged platform already meets the business requirement<\/li>\n<li>modernization effort would exceed the value of keeping the current codebase<\/li>\n<\/ul>\n<p>Replacement shifts the migration problem from infrastructure compatibility to business-process and data migration. The organization still needs to plan identity integration, data conversion, retention, reporting, user training, and cutover.<\/p>\n<p>A replacement can reduce technical debt dramatically, but it can also expose hidden process dependencies that the old system accumulated over many years.<\/p>\n<h2>Split a workload when one strategy cannot satisfy every component<\/h2>\n<p>Large applications rarely need one migration strategy for every tier.<\/p>\n<p>For example, an organization might:<\/p>\n<ul>\n<li>rehost a legacy application server temporarily<\/li>\n<li>replatform its database to a managed service<\/li>\n<li>refactor authentication to use Microsoft Entra ID<\/li>\n<li>rearchitect a batch-processing component into asynchronous workers<\/li>\n<li>replace an old reporting module with SaaS analytics<\/li>\n<\/ul>\n<p>This component-level approach can reduce risk because the team modernizes where the return is clear without forcing a complete rewrite before migration can begin.<\/p>\n<p>The challenge is dependency management. The migration sequence must preserve working interfaces between components that are moving at different speeds. Network paths, authentication, schema compatibility, and latency should be tested for every intermediate state, not only the final architecture.<\/p>\n<h2>Design the landing zone and connectivity before the cutover<\/h2>\n<p>A successful migration needs a target environment that is ready before workloads arrive.<\/p>\n<p>That includes decisions about:<\/p>\n<ul>\n<li>subscriptions and management groups<\/li>\n<li>identity and role assignments<\/li>\n<li>network address space and hybrid connectivity<\/li>\n<li>DNS and name resolution<\/li>\n<li>Azure Policy and security baselines<\/li>\n<li>centralized logging<\/li>\n<li>Key Vault and certificate dependencies<\/li>\n<li>backup and recovery<\/li>\n<li>cost allocation and tagging<\/li>\n<\/ul>\n<p>If these controls are added after migration, teams often create temporary exceptions that become permanent. A landing zone gives migrating workloads a governed destination from the beginning.<\/p>\n<p>Hybrid connectivity deserves particular attention during phased migration. When one tier remains on-premises and another moves to Azure, latency and firewall behavior can change dramatically. A topology that was acceptable inside one datacenter may perform poorly when every request crosses a WAN boundary.<\/p>\n<h2>Choose the cutover model around state and business tolerance<\/h2>\n<p>The migration path also determines how users move from the old environment to the new one.<\/p>\n<p>Common approaches include:<\/p>\n<ul>\n<li><strong>big-bang cutover<\/strong>, where the old system stops and the new system takes over<\/li>\n<li><strong>phased migration<\/strong>, where groups of users, regions, or components move gradually<\/li>\n<li><strong>parallel run<\/strong>, where old and new systems operate together for a controlled period<\/li>\n<li><strong>blue\/green-style cutover<\/strong>, where traffic is shifted between complete environments<\/li>\n<\/ul>\n<p>Stateful systems make cutover harder. Databases, file systems, queues, and caches may require final synchronization or write freezes to avoid losing transactions during the transition.<\/p>\n<p>Data migration also needs its own capacity and integrity plan. Estimate the initial transfer volume, the change rate while migration is in progress, the bandwidth available to Azure, and the time required for a final delta synchronization. Large datasets may need staged replication rather than one final copy window. After cutover, validate record counts, checksums, transaction consistency, or application-level invariants so the team is not relying only on \u201ccopy completed\u201d messages.<\/p>\n<p>Rollback must be defined before the change begins. If the new environment fails after users have written new data, simply pointing DNS back to the old environment may create consistency problems.<\/p>\n<p>After migration, measure whether the modernization delivered the intended value.<\/p>\n<p>Migration is complete only when the workload can be operated successfully in the new environment.<\/p>\n<p>The architecture team should verify whether the chosen strategy delivered the intended outcomes:<\/p>\n<ul>\n<li>lower infrastructure management effort<\/li>\n<li>improved availability<\/li>\n<li>faster deployments<\/li>\n<li>reduced cost<\/li>\n<li>better security controls<\/li>\n<li>improved observability<\/li>\n<li>easier scaling<\/li>\n<\/ul>\n<p>A rehosted workload may reveal itself as a good candidate for later replatforming once cloud usage data is available. A heavily modernized workload may show that some components became more complex without producing measurable business value.<\/p>\n<p>The important discipline is to avoid over-modernization and under-modernization for the same reason: migration strategy should follow the business and technical outcomes the organization actually needs.<\/p>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>Azure migration decisions are not simply choices between \u201cmove the server\u201d and \u201crewrite the application.\u201d A workload can be rehosted, replatformed, refactored, rearchitected, or replaced, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[125,29,30,47],"tags":[],"class_list":["post-3023","post","type-post","status-publish","format-standard","hentry","category-exam-az-305","category-certifications","category-cloud-computing","category-microsoft-certifications"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3023","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3023"}],"version-history":[{"count":2,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3023\/revisions"}],"predecessor-version":[{"id":4687,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3023\/revisions\/4687"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3023"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3023"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3023"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}