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.
Document control
| 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
1. Purpose, scope and decision summary
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
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
| 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
| 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
| 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
| 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
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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
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.