# Application Migration Assessment: [Application or workload name]

> Per-workload assessment that decides how one application moves to
> cloud and what it looks like afterwards: workload profile,
> dependencies and data gravity, licensing, readiness findings, the
> migration strategy chosen from the 7 Rs (retire, retain, rehost,
> relocate, repurchase, replatform, refactor or re-architect) with its
> rationale, target architecture, sizing, security and compliance
> deltas, migration method and tooling, tests, cutover and rollback, and
> cost before and after. The strategy vocabulary follows AWS
> Prescriptive Guidance (large migration guide, migration strategies);
> the steps map to the Microsoft Cloud Adoption Framework migrate
> guidance (Plan migration, Prepare workloads, Execute migration,
> Optimize in cloud, Decommission source) and the Google Cloud migration
> phases (Assess, Plan, Deploy, Optimize). Replace every `[bracketed]`
> value and every row marked *Example*; the examples follow an order
> management application moving from a virtualised data centre to a
> public cloud.

<!--
Guidance: How to use this template
- Write one assessment per workload (an application and everything it
  needs to run). The portfolio view, scoring of many applications and
  the strangler fig roadmap belong in the Legacy Modernization
  Assessment (`architecture/modernization-assessment`); wave grouping
  and the calendar belong in the Migration Wave Plan
  (`project/migration-wave-plan`). This document feeds both.
- Fill sections 2 to 5 from evidence (discovery tool data, CMDB,
  interviews, contracts) before you argue a strategy in section 7.
- Keep the decision in section 7 traceable: every rationale line cites
  a finding ID from sections 2 to 6.
- The cutover runbook itself lives in the Cutover Plan
  (`project/cutover-plan`); section 13 here records only the method,
  timings and rollback triggers that shaped the decision.
- Related documents: Cloud Adoption Strategy
  (`architecture/cloud-adoption-strategy`), Landing Zone Design
  (`architecture/landing-zone-design`), Network Architecture Design
  (`architecture/network-architecture-design`), Data Migration Strategy
  (`architecture/data-migration-strategy`), Resilience Tiering and HA/DR
  Design (`architecture/resilience-tiering-ha-dr-design`), TCO Analysis
  (`architecture/tco-analysis`).
-->

## Document control

<!-- Guidance: Identify the workload, its business owner and the target platform. A change of migration strategy or target platform is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [AMA-001] |
| Workload name and ID | [Name], [WL-NNNN from the CMDB or portfolio] |
| Business owner | [@business-owner] |
| Technical owner | [@application-lead] |
| Target platform | [Provider], [region], [landing zone container] |
| Proposed strategy | [Retire / Retain / Rehost / Relocate / Repurchase / Replatform / Refactor] |
| Proposed wave | [Wave ID from the Migration Wave Plan] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@migration-architect] |
| Approvers/reviewers | [@business-owner], [@security-architect], [@platform-lead], [@finops-lead] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Portfolio assessment], [Wave plan], [Landing zone design], [Cutover plan] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Migration architect | [@name] | [Decision] | YYYY-MM-DD |
| Security | [@name] | [Decision] | YYYY-MM-DD |
| Platform and operations | [@name] | [Decision] | YYYY-MM-DD |
| Finance and FinOps | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from discovery data |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Dependency findings confirmed in workshop, strategy changed from rehost to replatform |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by migration board, assigned to wave W3 |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose, scope and decision summary](#1-purpose-scope-and-decision-summary)
2. [Workload profile](#2-workload-profile)
3. [Current architecture and dependencies](#3-current-architecture-and-dependencies)
4. [Data profile and data gravity](#4-data-profile-and-data-gravity)
5. [Licensing and contractual constraints](#5-licensing-and-contractual-constraints)
6. [Readiness findings](#6-readiness-findings)
7. [Migration strategy and rationale](#7-migration-strategy-and-rationale)
8. [Target architecture](#8-target-architecture)
9. [Sizing and performance](#9-sizing-and-performance)
10. [Security, compliance and resilience deltas](#10-security-compliance-and-resilience-deltas)
11. [Migration method and tooling](#11-migration-method-and-tooling)
12. [Test strategy and acceptance criteria](#12-test-strategy-and-acceptance-criteria)
13. [Cutover and rollback](#13-cutover-and-rollback)
14. [Cost before and after](#14-cost-before-and-after)
15. [Risks, assumptions and open issues](#15-risks-assumptions-and-open-issues)
16. [Decision record and traceability](#16-decision-record-and-traceability)
17. [Glossary and references](#17-glossary-and-references)

## 1. Purpose, scope and decision summary

<!-- Guidance: Give a reader who stops here the decision, the reason and the cost. Questions: why is this workload moving now? What happens if it does not move? Pitfall: a summary that restates the template headings instead of the decision. -->

### 1.1 Purpose

This assessment decides how [Application name] leaves [source
environment] and what it runs on afterwards. It records the evidence,
the options considered, the chosen strategy and the conditions attached
to approval. The migration board uses it to accept the workload into a
wave; the delivery team uses it as the design baseline.

### 1.2 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Order management web tier, API tier, batch jobs and Oracle database `ORDPRD` | Warehouse management system that calls the order API (assessed separately as WL-0217) |
| *Example:* Non-production environments (test, pre-production) | End-user devices and the corporate identity provider |
| *Example:* Interfaces to ERP, payment gateway and data warehouse | Re-design of business processes |
| [Item] | [Item] |

### 1.3 Decision summary

| Item | Summary |
|---|---|
| Recommended strategy | *Example:* Replatform: application servers rehosted to cloud VMs, database moved from Oracle to a managed PostgreSQL service |
| Main reasons | *Example:* Oracle support renewal due in 10 months (LIC-002), low database feature use (FND-006), hardware end of support (FND-001) |
| Target | *Example:* Public cloud region [Region 1], production spoke in the landing zone, warm standby in [Region 2] |
| Migration window | *Example:* Wave W3, cutover weekend YYYY-MM-DD, 6-hour outage window |
| Run cost change | *Example:* USD 206,000 to USD 148,800 per year, a saving of USD 57,200 (section 14) |
| One-time cost and payback | *Example:* USD 151,200, payback about 32 months |
| Conditions | *Example:* Schema conversion proof completed before W3 freeze; payment gateway IP allow list updated by the provider |

## 2. Workload profile

<!-- Guidance: Describe the workload as it runs today, from discovery data rather than memory. Questions: who uses it, when, how much, and what breaks if it stops? Pitfall: inventory copied from an old CMDB entry that misses servers added since. -->

### 2.1 Business profile

| Attribute | Value | Source |
|---|---|---|
| Business capability | *Example:* Order capture and fulfilment orchestration | Capability map |
| Users | *Example:* 1,200 internal users, 40 partner integrations | Identity logs, API gateway |
| Peak periods | *Example:* Month end, last two weeks of November | Business owner interview |
| Business criticality tier | *Example:* Tier 1 (resilience tiering) | Resilience tiering design |
| Current availability target | *Example:* 99.9 % monthly, business hours 06:00 to 22:00 | SLA register |
| RTO and RPO | *Example:* RTO 4 hours, RPO 15 minutes | BIA |
| Maximum tolerable outage for cutover | *Example:* 8 hours on a weekend night | Business owner |
| Change frequency | *Example:* Monthly release, quarterly major release | Release calendar |

### 2.2 Technical inventory

| Component ID | Component | Technology and version | Hosts | CPU / memory (allocated) | Peak use (95th percentile, 30 days) | Support status |
|---|---|---|---|---|---|---|
| CMP-001 *(Example)* | Web tier | Nginx 1.24 on RHEL 8 | 2 VMs | 4 vCPU / 8 GiB each | 22 % CPU, 41 % memory | Supported |
| CMP-002 *(Example)* | API tier | Java 17, Spring Boot 3.2 on RHEL 8 | 4 VMs | 8 vCPU / 32 GiB each | 38 % CPU, 62 % memory | Supported |
| CMP-003 *(Example)* | Batch scheduler and jobs | Cron plus shell scripts, Java jobs | 1 VM | 4 vCPU / 16 GiB | 71 % CPU at 02:00 | Supported |
| CMP-004 *(Example)* | Database | Oracle Database 19c Enterprise Edition, single instance | 1 physical host | 16 cores / 256 GiB | 34 % CPU, 1.8 TB data | Hardware support ends YYYY-MM-DD |
| CMP-005 *(Example)* | File share | NFS export on NAS | Shared NAS | Not applicable | 420 GB, 2 million files | Supported |
| [CMP-NNN] | [Component] | [Technology] | [Hosts] | [Allocated] | [Observed] | [Status] |

Record the discovery tool, collection period and gaps. A collection
period shorter than one full business cycle (usually a month, including
month end) under-states peaks.

## 3. Current architecture and dependencies

<!-- Guidance: Map every inbound and outbound dependency, including the ones nobody owns. Questions: which dependencies need low latency? Which can tolerate a hybrid period? Which are hard-coded IP addresses? Pitfall: missing a nightly file transfer that only appears in the batch scheduler. -->

```mermaid
flowchart LR
  U[Internal users] --> WEB[Web tier CMP-001]
  P[Partners] --> APIGW[On-premises API gateway]
  APIGW --> API[API tier CMP-002]
  WEB --> API
  API --> DB[(Oracle ORDPRD CMP-004)]
  BATCH[Batch CMP-003] --> DB
  BATCH --> NFS[(File share CMP-005)]
  API --> ERP[ERP system]
  API --> PAY[Payment gateway, external]
  DB --> DWH[Data warehouse nightly extract]
  WMS[Warehouse system WL-0217] --> API
```

| Dependency ID | From | To | Protocol and port | Direction | Volume and latency need | Type | Migration handling |
|---|---|---|---|---|---|---|---|
| DEP-001 *(Example)* | API tier | Oracle ORDPRD | Oracle Net, TCP 1521 | Outbound | 3,000 queries per second, under 2 ms | Direct | Move together (same move group) |
| DEP-002 *(Example)* | API tier | ERP | REST over HTTPS | Outbound | 50 requests per second, under 200 ms | Indirect | Stays on premises; hybrid link through hub |
| DEP-003 *(Example)* | Warehouse system | API tier | REST over HTTPS | Inbound | 20 requests per second | Indirect | DNS name change only, no code change |
| DEP-004 *(Example)* | API tier | Payment gateway | HTTPS to fixed IP allow list | Outbound | 5 requests per second | External | Provider must add new egress IPs before cutover |
| DEP-005 *(Example)* | Batch | Data warehouse | SFTP file drop, 02:30 daily | Outbound | 6 GB per night | Business | Keep schedule, new source IP |
| DEP-006 *(Example)* | All tiers | Corporate directory | LDAPS, Kerberos | Outbound | Low | Shared service | Use cloud-side domain controllers in hub |
| [DEP-NNN] | [From] | [To] | [Protocol] | [Direction] | [Need] | [Direct / Indirect / Business / External / Shared] | [Handling] |

Classify each dependency the way the CAF migrate guidance suggests:
direct dependencies move together, indirect dependencies may run across
environments for a limited period, business dependencies follow
business grouping. Record every hard-coded IP address and certificate
bound to a host name; both are common cutover blockers.

## 4. Data profile and data gravity

<!-- Guidance: Data volume, change rate and latency coupling decide the migration method more often than application code does. Pitfall: sizing the transfer on database size and forgetting logs, files and backups that must also move. -->

| Data set ID | Data set | Store | Size | Daily change | Classification | Residency constraint | Retention |
|---|---|---|---|---|---|---|---|
| DAT-001 *(Example)* | Orders and customers | Oracle ORDPRD | 1.8 TB | 14 GB redo per day | Confidential, contains personal data | Must stay in [EU / country] | 10 years |
| DAT-002 *(Example)* | Order documents | NFS share | 420 GB | 3 GB per day | Confidential | Same | 7 years |
| DAT-003 *(Example)* | Archived orders | Tape and cold storage | 6 TB | None | Confidential | Same | 10 years; not migrated, retrieval process unchanged |
| [DAT-NNN] | [Data set] | [Store] | [Size] | [Change] | [Class] | [Constraint] | [Retention] |

### 4.1 Transfer estimate

*Example:* With a 1 Gbit/s private link and 50 % of it usable for
migration, the effective rate is 500 Mbit/s, which is 62.5 MB/s. The
initial copy of DAT-001 (1.8 TB, that is 1,800,000 MB) takes
1,800,000 / 62.5 = 28,800 seconds, or 8 hours. Changes made during the
copy are replicated with change data capture until cutover, so the
outage window only covers the final synchronisation, validation and
switch. DAT-002 (420 GB) takes about 1.9 hours at the same rate and is
pre-seeded the week before.

### 4.2 Data gravity findings

| Finding ID | Finding | Consequence |
|---|---|---|
| FND-101 *(Example)* | The data warehouse extract reads 6 GB a night over the link after migration | Within link capacity; egress charges included in section 14 |
| FND-102 *(Example)* | ERP calls are chatty (12 calls per order) and latency-sensitive | Measure added latency in the proof (TST-004); cache reference data in the API tier if over 40 ms per order |
| [FND-NNN] | [Finding] | [Consequence] |

## 5. Licensing and contractual constraints

<!-- Guidance: Licences and contracts often decide the strategy. Questions: does the licence allow the target platform? What notice periods and renewal dates apply? Pitfall: assuming on-premises licences can move to any cloud without checking the vendor's licence mobility terms. -->

| ID | Item | Current terms | Constraint on migration | Action |
|---|---|---|---|---|
| LIC-001 *(Example)* | Operating system subscriptions | Per-socket data centre subscription | Cloud VMs can use provider-included licences | Drop on-premises subscriptions at decommission |
| LIC-002 *(Example)* | Oracle Database Enterprise Edition and support | Processor licences, support renews YYYY-MM-DD | Licence counting differs on public cloud; check the vendor's current cloud policy | Replatform to PostgreSQL before renewal, or renew for 12 months only |
| LIC-003 *(Example)* | Monitoring agent | Per-host licence | Transferable | Re-register hosts |
| LIC-004 *(Example)* | Data centre hosting contract | Rack contract, 6 months notice | Exit date drives wave timing | Give notice by YYYY-MM-DD |
| [LIC-NNN] | [Item] | [Terms] | [Constraint] | [Action] |

Check each commercial software licence against the vendor's current
licence terms for the target provider. Record who confirmed it and when;
this is a contract question, not an architecture opinion.

## 6. Readiness findings

<!-- Guidance: Score readiness on a few explicit criteria and keep the evidence. Questions: what would make each strategy fail? Pitfall: scores with no evidence column, which nobody can challenge. -->

| Criterion | Score (1 low to 5 high) | Evidence | Finding IDs |
|---|---|---|---|
| Business value of keeping the capability *(Example)* | 5 | Core order flow, revenue-bearing | FND-002 |
| Technical health *(Example)* | 3 | Supported runtime, low test coverage on batch jobs | FND-003, FND-004 |
| Cloud compatibility of the stack *(Example)* | 4 | Linux, Java, no special hardware | FND-005 |
| Database portability *(Example)* | 4 | 96 % of PL/SQL objects convertible by assessment tool; 14 packages need manual work | FND-006 |
| Operational maturity *(Example)* | 3 | Runbooks exist, no infrastructure as code | FND-007 |
| Team skills on target platform *(Example)* | 2 | Two engineers certified, none on managed PostgreSQL | FND-008 |
| Urgency *(Example)* | 5 | Database host out of support in 9 months | FND-001 |

| Finding ID | Finding | Severity | Owner |
|---|---|---|---|
| FND-001 *(Example)* | Database host hardware support ends YYYY-MM-DD | High | @infra-lead |
| FND-002 *(Example)* | Core revenue capability; no replacement product is planned or budgeted | Low | @business-owner |
| FND-003 *(Example)* | Batch jobs reference absolute NFS paths and host names | Medium | @application-lead |
| FND-004 *(Example)* | Batch jobs have low automated test coverage (about 20 % of job paths) | Medium | @application-lead |
| FND-005 *(Example)* | Stack is Linux and Java with no special hardware, dongles or kernel modules | Low | @platform-lead |
| FND-006 *(Example)* | Database uses no partitioning, no RAC, no advanced Oracle options | Low | @dba-lead |
| FND-007 *(Example)* | Runbooks exist, but no infrastructure as code; servers are built by hand | Medium | @platform-lead |
| FND-008 *(Example)* | Skills gap on managed database operations | Medium | @platform-lead |
| [FND-NNN] | [Finding] | [H / M / L] | [@owner] |

## 7. Migration strategy and rationale

<!-- Guidance: Consider every strategy, reject the ones that do not fit with a reason, and state the chosen one with its conditions. Use the provider's own definitions; do not invent new Rs. Pitfall: choosing refactor during a large migration because it is attractive, when the guidance favours moving first and modernising after. -->

### 7.1 Strategy vocabulary

| Strategy | Meaning in this assessment |
|---|---|
| Retire | Decommission or archive; the capability is no longer needed or is provided elsewhere |
| Retain | Keep in the source environment for now, with a documented reason and review date |
| Rehost | Move servers to cloud VMs without changing the application (lift and shift) |
| Relocate | Move a whole virtualised platform or a cloud resource to a new location without changing the workload (for example a hypervisor cluster to the provider's hosted version) |
| Repurchase | Replace with a different product, usually SaaS (drop and shop) |
| Replatform | Move with targeted optimisation, such as a managed database or containers, without changing the core architecture |
| Refactor or re-architect | Change the architecture to use cloud-native capabilities |

Google Cloud publishes a comparable list (rehost, replatform, refactor,
re-architect, rebuild, repurchase). If your organisation uses that
list, map "rebuild" (rip and replace) to refactor or re-architect
when the team rewrites the application, or to repurchase when it buys a
replacement, and keep the mapping in the glossary.

### 7.2 Options considered

| Option ID | Strategy | Description | For | Against | Verdict |
|---|---|---|---|---|---|
| OPT-1 *(Example)* | Retain | Renew hardware and Oracle support | No migration effort | Capital spend, licence cost, conflicts with data centre exit (LIC-004) | Rejected |
| OPT-2 *(Example)* | Rehost | All tiers including Oracle to cloud VMs | Fast, low change | Oracle licence position on cloud unclear (LIC-002); keeps database administration burden | Fallback if OPT-3 proof fails |
| OPT-3 *(Example)* | Replatform | Application tiers rehosted, Oracle to managed PostgreSQL, NFS to managed file service | Removes database licence and host management; moderate change | Schema conversion work (FND-006), skills gap (FND-008) | **Chosen** (see note) |
| OPT-4 *(Example)* | Repurchase | Move to a SaaS order management product | Removes run burden | 18-month programme, process change, outside data centre exit date | Rejected for now, review in 2 years |
| OPT-5 *(Example)* | Refactor | Split into services on containers with event streaming | Long-term agility | Highest cost and risk, not needed for exit | Deferred to post-migration modernisation |
| [OPT-N] | [Strategy] | [Description] | [For] | [Against] | [Verdict] |

Note on OPT-3: the application tiers are replatformed, but the change of
database engine (Oracle to PostgreSQL, with 14 PL/SQL packages
converted by hand) is a database refactor in much provider guidance,
which reserves "replatform" for a same-engine move such as SQL Server to
a managed SQL Server service. If your provider or programme vocabulary
does that, record the database tier as refactor and keep the effort and
risk figures unchanged.

### 7.3 Decision

| Item | Value |
|---|---|
| Chosen strategy | *Example:* Replatform (OPT-3) |
| Rationale | *Example:* Meets the exit date (LIC-004) and hardware deadline (FND-001), removes Oracle renewal (LIC-002), conversion risk is bounded (FND-006) |
| Conditions | *Example:* Conversion proof passes TST-002 by YYYY-MM-DD; two engineers complete managed database training (FND-008) |
| Fallback | *Example:* OPT-2 rehost with a 12-month Oracle renewal, decided at the proof gate |
| Post-migration modernisation | *Example:* Batch jobs to managed scheduler and object storage in the quarter after hypercare |

## 8. Target architecture

<!-- Guidance: Show the target at the level a reviewer can check against the landing zone. Questions: which container, network spoke and services? What changes for operations? Pitfall: a target diagram that ignores the dependencies still on premises. -->

```mermaid
flowchart LR
  subgraph Cloud[Region 1, production spoke]
    LB[Load balancer with WAF] --> WEBC[Web tier VMs, 2 zones]
    WEBC --> APIC[API tier VMs, 2 zones]
    APIC --> PG[(Managed PostgreSQL, zone-redundant)]
    JOBS[Batch VMs] --> PG
    JOBS --> FS[(Managed file service)]
  end
  HUB[Hub: firewall, DNS, private link to on premises]
  APIC --> HUB
  HUB --> ERP2[ERP on premises]
  HUB --> PAY2[Payment gateway via central egress]
  PG -. replication .-> DR[(Standby in Region 2)]
```

| Target element | Choice | Landing zone reference |
|---|---|---|
| Container *(Example)* | `orders-prod-euw` in Workloads / Production | Landing zone section 3 |
| Network *(Example)* | Spoke /22 from the regional pool, routed through the hub firewall | Network architecture design, IP plan |
| Compute *(Example)* | General-purpose VMs across two zones, autoscaling group for the API tier | Infrastructure design |
| Database *(Example)* | Managed PostgreSQL [version], zone-redundant, private endpoint only | Section 10 |
| Files *(Example)* | Managed NFS-compatible file service, private endpoint | Section 10 |
| Identity *(Example)* | Workload identity for service access; users through the existing identity provider | Landing zone section 4 |
| Observability *(Example)* | Agent-based metrics and logs to the central platform | Observability specification |
| Infrastructure as code *(Example)* | Terraform or OpenTofu modules from the platform catalogue | Infrastructure design |

## 9. Sizing and performance

<!-- Guidance: Size from observed use, not from allocated capacity, and keep headroom explicit. Pitfall: copying on-premises VM sizes one to one, which usually over-provisions. -->

| Component | Observed peak | Target size | Headroom rule | Count |
|---|---|---|---|---|
| Web tier *(Example)* | 22 % of 4 vCPU per VM (0.88 vCPU) | 2 vCPU / 8 GiB | Peak under 60 % of target per VM (0.88 / 2 = 44 %) | 2, one per zone |
| API tier *(Example)* | 38 % of 8 vCPU per VM on 4 VMs (3.04 vCPU each, 12.16 vCPU in total), 20 GiB used per VM (80 GiB in total) | 4 vCPU / 32 GiB | Peak under 60 % per VM at the baseline count (12.16 / 24 = 51 %; memory 80 / 192 = 42 %), autoscale to 8 | 6 baseline, 3 per zone |
| Batch *(Example)* | 71 % of 4 vCPU for 90 minutes | 4 vCPU / 16 GiB | Run window under 2 hours | 1 |
| Database *(Example)* | 34 % of 16 physical cores (5.44 cores), 1.8 TB | 16 vCPU / 128 GiB (8 physical cores at 2 threads per core), 4 TB storage | CPU peak under 70 % of physical cores (5.44 / 8 = 68 %); storage under 70 % after 24 months at 40 GB per month growth ((1.8 + 0.96) / 4 = 69 %) | 1 primary, plus a warm standby at 8 vCPU scaled to 16 vCPU on promotion |
| [Component] | [Observed] | [Target] | [Rule] | [Count] |

Convert units before you compare: an on-premises "core" is a physical
core, while most providers sell vCPUs that are hardware threads, so one
physical core is usually two vCPUs. The database row is the tightest in
this example (68 % against a 70 % rule); TST-004 confirms it, and the
fallback is the next size up (32 vCPU), costed as a sensitivity in the
TCO Analysis.

| Performance requirement | Current baseline | Target | Test |
|---|---|---|---|
| Order submission p95 *(Example)* | 420 ms | 450 ms or better | TST-004 |
| Order search p95 *(Example)* | 900 ms | 900 ms or better | TST-004 |
| Nightly batch duration *(Example)* | 95 minutes | Under 120 minutes | TST-005 |
| [Requirement] | [Baseline] | [Target] | [TST-NNN] |

Capture the baseline before migration with the same tool and test you
will use afterwards. A target without a measured baseline cannot be
accepted or rejected.

## 10. Security, compliance and resilience deltas

<!-- Guidance: List what changes, not the whole security design. Questions: which controls move to the provider? Which new controls are needed? Does the resilience tier change? Pitfall: assuming the on-premises firewall rules translate directly to cloud security groups. -->

| Delta ID | Area | Current | Target | Action | Owner |
|---|---|---|---|---|---|
| SEC-001 *(Example)* | Network exposure | Partner API published through on-premises gateway | Published through cloud load balancer with WAF | Migrate WAF rules, penetration test before go-live | @security-architect |
| SEC-002 *(Example)* | Encryption at rest | Oracle TDE on selected tablespaces | Provider encryption with customer-managed key | Create key, rotation yearly | @platform-lead |
| SEC-003 *(Example)* | Database access | Named DBA accounts on the host | Managed service roles, just-in-time elevation | Map roles, remove shared accounts | @dba-lead |
| SEC-004 *(Example)* | Personal data | Processed in own data centre | Processed by cloud provider in [region] | Update record of processing and DPIA screening | @privacy-officer |
| SEC-005 *(Example)* | Logging | Local syslog, 30 days | Central log archive, 1 year | Agent and retention configuration | @security-operations |
| RES-001 *(Example)* | Disaster recovery | Restore from tape at second site, RTO 24 hours | Warm standby database in Region 2, RTO 4 hours | Implement per resilience tiering design | @platform-lead |
| [SEC-NNN] | [Area] | [Current] | [Target] | [Action] | [@owner] |

## 11. Migration method and tooling

<!-- Guidance: Choose the method per component and say why. Questions: offline or online copy? Replication tool? How is the final sync bounded? Pitfall: choosing a near-zero downtime method without testing that the link and the tool can keep up with the change rate. -->

| Component | Method | Tool category | Downtime class | Rationale |
|---|---|---|---|---|
| Web and API tiers *(Example)* | Rebuild from IaC and deploy the same artefacts | Pipeline, image builder | None (parallel build) | Stateless, existing CI artefacts |
| Batch *(Example)* | Rebuild, path changes per FND-003 | Pipeline | Within cutover window | Scripts need edits |
| Database *(Example)* | Schema conversion, full load, then change data capture until cutover | Schema conversion tool, database migration service | Near-zero (final sync under 30 minutes) | 1.8 TB with 14 GB daily change (DAT-001) |
| Files *(Example)* | Pre-seed copy, incremental sync, final delta at cutover | File transfer service | Within cutover window | 420 GB, small daily change |
| [Component] | [Method] | [Tool] | [None / Near-zero / Outage] | [Rationale] |

Name the actual tools in the delivery plan once the platform team has
approved them. Provider migration programmes (for example the AWS
Migration Acceleration Program phases Assess, Mobilize, and Migrate and
Modernize) may fund or supply tooling; record any such dependency here.

## 12. Test strategy and acceptance criteria

<!-- Guidance: Tie every test to an acceptance criterion and an owner. Pitfall: testing that the application starts instead of testing that it meets its baseline. -->

| Test ID | Test | Environment | Acceptance criterion | Owner |
|---|---|---|---|---|
| TST-001 *(Example)* | Infrastructure validation | Target pre-production | All guardrail checks pass, no public exposure | @platform-lead |
| TST-002 *(Example)* | Schema and code conversion proof | Target test | All 14 manual packages converted; functional suite 100 % pass | @dba-lead |
| TST-003 *(Example)* | Data reconciliation | Target test, then production rehearsal | Row counts and checksums match for all tables; see Data Migration Reconciliation (`project/data-migration-reconciliation`) | @data-lead |
| TST-004 *(Example)* | Performance against baseline | Target pre-production | Section 9 targets met at 1.5 times peak load | @performance-lead |
| TST-005 *(Example)* | Batch run | Target pre-production | Completes under 120 minutes, outputs identical | @application-lead |
| TST-006 *(Example)* | Interface tests | Target pre-production | All DEP rows exercised end to end | @integration-lead |
| TST-007 *(Example)* | Failover and restore | Target pre-production | Standby promoted and scaled to 16 vCPU within RTO; restore within RPO | @platform-lead |
| TST-008 *(Example)* | Cutover rehearsal | Production rehearsal | Full runbook within 5 hours, rollback rehearsed | @migration-lead |
| [TST-NNN] | [Test] | [Environment] | [Criterion] | [@owner] |

## 13. Cutover and rollback

<!-- Guidance: Record the cutover shape and the rollback triggers that the decision depends on; the step-by-step runbook belongs in the cutover plan. Pitfall: a rollback that is impossible once writes begin on the target, discovered during cutover. -->

| Item | Design |
|---|---|
| Cutover approach *(Example)* | Single weekend cutover after change data capture catch-up; DNS switch for users and partners |
| Outage window *(Example)* | 6 hours planned, inside the 8-hour tolerance (section 2.1) |
| Point of no return *(Example)* | Two hours after the target accepts writes; after that, rollback needs reverse replication |
| Reverse path *(Example)* | Reverse change data capture from PostgreSQL to Oracle kept running for 7 days |
| Rollback triggers *(Example)* | Reconciliation mismatch, order submission p95 over 1 second for 15 minutes, payment failures over 2 % |
| Decision owner *(Example)* | Business owner on advice of the migration lead |
| Hypercare *(Example)* | 14 days, see Hypercare Plan (`ops/hypercare-plan`) |
| Source decommission *(Example)* | Source kept read-only for 30 days, then archived and removed; licences cancelled per section 5 |

## 14. Cost before and after

<!-- Guidance: Compare like for like over the same period and show one-time costs separately. Pitfall: leaving out labour, dual running and data transfer, which makes the cloud case look better than it is. -->

| Cost line (per year) | Current, USD | Target, USD | Notes |
|---|---|---|---|
| Hosting and hardware *(Example)* | 38,400 | 0 | Depreciation and maintenance |
| Virtualisation licences *(Example)* | 14,600 | 0 | Share of cluster licences |
| Database licences and support *(Example)* | 61,200 | 0 | Removed by replatform |
| Data centre facilities *(Example)* | 19,800 | 0 | Space, power, cooling share |
| Compute *(Example)* | 0 | 36,800 | Section 9 sizes (32 vCPU at USD 1,150 per vCPU-year), one-year commitment |
| Managed database including standby *(Example)* | 0 | 46,800 | 16 vCPU primary and 8 vCPU Region 2 standby at USD 1,950 per vCPU-year, database storage included |
| Storage and backup *(Example)* | 0 | 6,900 | Files, snapshots, backups |
| Network and data transfer *(Example)* | 0 | 4,800 | Hub share, egress to warehouse |
| Monitoring and security tooling *(Example)* | 0 | 5,500 | Agents, WAF, key management |
| Operations labour *(Example)* | 72,000 | 48,000 | 0.9 to 0.6 FTE at USD 80,000 |
| **Total** *(Example)* | **206,000** | **148,800** | Saving 57,200 per year (27.8 %) |

| One-time cost | USD | Notes |
|---|---|---|
| Migration labour *(Example)* | 96,000 | Assessment, build, conversion, tests, cutover |
| Conversion tooling and specialist services *(Example)* | 18,000 | Database conversion support |
| Dual running, 3 months *(Example)* | 37,200 | Target run cost for 3 months (148,800 / 4) while the source still runs |
| **Total** *(Example)* | **151,200** | Payback 151,200 / 57,200 = 2.64 years, about 32 months |

Keep the full model in the TCO Analysis (`architecture/tco-analysis`)
and review actual spend after three months with the FinOps Cost Review
(`ops/finops-cost-review`).

## 15. Risks, assumptions and open issues

<!-- Guidance: Keep risks specific to this workload and give each a response. Pitfall: generic migration risks copied from a programme register. -->

| ID | Type | Description | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|---|
| RSK-001 *(Example)* | Risk | Manual PL/SQL conversion takes longer than planned | Medium | High | Proof gate TST-002; fallback OPT-2 | @dba-lead |
| RSK-002 *(Example)* | Risk | Payment gateway provider is slow to update the IP allow list | Medium | High | Request 6 weeks before cutover; use a fixed egress IP range | @integration-lead |
| RSK-003 *(Example)* | Risk | ERP latency over the hybrid link slows order submission | Low | Medium | TST-004 with ERP in loop; caching option (FND-102) | @application-lead |
| ASM-001 *(Example)* | Assumption | Landing zone production spoke ready by YYYY-MM-DD | Not applicable | Not applicable | Confirm with platform team at wave planning | @platform-lead |
| ISS-001 *(Example)* | Open issue | Retention of archived orders on tape after the data centre exit | Not applicable | Not applicable | Decision by records manager | @records-manager |
| [ID] | [Risk / Assumption / Issue] | [Description] | [L / M / H] | [L / M / H] | [Response] | [@owner] |

Record programme-level items in the RAID log (`project/raid-log`).

## 16. Decision record and traceability

<!-- Guidance: Show that the decision follows from the evidence and that every condition has a test. Pitfall: approval conditions that no test or gate ever checks. -->

| Decision element | Evidence | Condition or test | Status |
|---|---|---|---|
| Replatform chosen (OPT-3) *(Example)* | FND-001, FND-006, LIC-002, LIC-004 | TST-002 proof gate | [Open / Met] |
| Target in Region 1 with standby in Region 2 *(Example)* | Section 2.1 tier and RTO | TST-007 | [Status] |
| 6-hour outage window *(Example)* | Section 4.1 estimate, section 11 method | TST-008 rehearsal | [Status] |
| Run cost USD 148,800 *(Example)* | Section 14 | FinOps review at month 3 | [Status] |
| [Element] | [Evidence] | [Test or gate] | [Status] |

Record the final decision as an entry in the Architecture Decision Log
(`architecture/architecture-decision-log`) and hand the approved
assessment to the wave planning team.

## 17. Glossary and references

<!-- Guidance: Define the migration terms used here and list the sources with the date you checked them. -->

### 17.1 Glossary

| Term | Meaning |
|---|---|
| Workload | An application and the infrastructure, data and interfaces it needs to deliver a business capability |
| 7 Rs | The seven migration strategies used in section 7 |
| Move group | Set of components that must migrate together because of direct dependencies |
| Change data capture | Continuous replication of changes from a source database to a target |
| Data gravity | The tendency of large or latency-coupled data to pull applications and services towards it |
| Point of no return | The moment after which rollback needs a separate reverse migration |
| Dual running | Period in which source and target both run and both cost money |
| Hypercare | Period of heightened support after go-live |

### 17.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| AWS Prescriptive Guidance, Guide for AWS large migrations, "About the migration strategies", docs.aws.amazon.com | Current web edition, checked YYYY-MM-DD | Strategy definitions in section 7 |
| AWS Migration Acceleration Program, aws.amazon.com/migration-acceleration-program | Checked YYYY-MM-DD | Phases Assess, Mobilize, Migrate and Modernize |
| Microsoft Cloud Adoption Framework, Adopt, "Plan your migration", learn.microsoft.com | Page dated August 2025, updated March 2026 | Dependency types, migration methods, rollback planning |
| Google Cloud, "Migrate to Google Cloud: Get started", docs.cloud.google.com | Page updated November 2024 | Phases Assess, Plan, Deploy, Optimize; migration types |
| [Discovery tool report] | [Date] | Sections 2 to 4 |
| [Vendor licence terms] | [Date] | Section 5 |

## Standard and licence note

Based on the migration strategies published in AWS Prescriptive
Guidance (the 7 Rs), the migrate guidance of the Microsoft Cloud
Adoption Framework and the Google Cloud migration phases, used for
vocabulary and structure only. All text, tables and examples in this
template are original and were written for this collection; no
provider checklist wording is reproduced. Check the current official
pages before use, because provider guidance and programme names change.
AWS, Microsoft Azure, Google Cloud and the products named are
trademarks of their owners; this template is not affiliated with or
endorsed by them. Template licence: MIT.