Downloadable planning resources

Cloudwrxs planning resource library

Practical checklists and decision guides that help teams review AWS, SAP, Oracle, risk and assessment readiness before delivery work starts.

7 resources CSV free downloads 126 planning rows
AWS foundation

AWS Landing Zone Planning Checklist

Practical questions for reviewing accounts, identity, governance, logging, networking, operations and cost before workloads move onto AWS.

18 planning rows 3.9 KB Updated 2026-06-29
Preview planning questions
area planning question evidence or decision next action
Business drivers Which business outcomes should the landing zone support: migration, resilience, compliance, cost control or product velocity? Executive sponsor, migration business case, risk register Document the landing-zone success criteria before selecting tooling
Application scope Which workloads, teams, environments and security boundaries need separate AWS accounts? Current application inventory, environment map, ownership model Define an account vending pattern before broad migration starts
Account structure Which accounts are required for management, logging, security, shared services, network, production, non-production and sandbox use? Account taxonomy, OU model, workload criticality tiers Build the account and OU model before onboarding workloads
Region strategy Which AWS regions must be enabled, blocked or monitored? Data residency requirements, latency needs, service availability Create region enablement rules and exception process
Network design Which VPC, transit, DNS, ingress, egress and inspection patterns are required? IP plan, connectivity diagrams, routing constraints Confirm landing-zone network guardrails and exception routes
Identity and access How will users, administrators, break-glass access and workload roles authenticate? Identity provider, role catalogue, privileged access process Map IAM Identity Center permission sets and operational roles
Privileged access How will privileged activity be approved, logged, time-limited and reviewed? Admin role catalogue, approval process, audit requirements Define break-glass and just-in-time access runbooks
Security guardrails Which controls must be preventative, detective or advisory? Regulatory needs, baseline controls, security tooling Prioritise SCPs, AWS Config rules, logging and alerting
Logging and audit Where will CloudTrail, Config, VPC Flow Logs and security findings be centralised? Retention requirements, SIEM/SOC integration needs Create central logging and security account design
Threat detection Which AWS native or third-party services will cover threat detection and vulnerability visibility? GuardDuty, Security Hub, Inspector, Access Analyzer, SOC requirements Define detection coverage and escalation paths
Backup and recovery Which landing-zone services and workloads need backup, restore and cross-account recovery patterns? RPO/RTO requirements, backup policy, recovery test history Create backup policies and recovery test calendar
Operations model Who owns platform operations, incident response, patching and cost governance? RACI, support hours, runbook ownership Agree operating model before onboarding production workloads
Change management How will platform changes, account vending and guardrail exceptions be requested and approved? ITSM process, Git workflow, approval matrix Create change workflows for common platform requests
Cost governance How will budgets, tagging, chargeback and anomaly detection be enforced? Finance reporting needs, tag taxonomy, budget owners Create mandatory tags and budget alert patterns
Workload onboarding What evidence must each workload provide before entering the landing zone? Architecture review, data classification, DR plan, support model Create a workload onboarding checklist
Migration waves How will accounts and shared services support phased migration waves? Wave plan, dependency map, landing-zone capacity assumptions Align account provisioning and network readiness to migration waves
Policy exceptions How will exceptions to SCPs, regions, encryption and networking rules be requested and expired? Exception register, risk owner, expiry date Define exception lifecycle and review cadence
Validation tests How will the landing zone be tested before production use? Control evidence, penetration test scope, logging validation, recovery test Run a pre-production landing-zone validation exercise
SAP support planning

SAP NetWeaver Support Planning Matrix

Turn NetWeaver, BW, Enterprise Portal and PI/PO risk into discovery questions and clear upgrade or migration decisions.

18 planning rows 3.7 KB Updated 2026-06-29
Preview planning questions
component typical risk planning question recommended action
SAP NetWeaver ABAP Legacy basis stack, operating system or database dependency Is the system still on a supported SAP, OS and database combination? Confirm support status and define upgrade or migration path
SAP NetWeaver Java Java stack dependency, old portal or integration runtime Which Java applications or services still run on the platform? Inventory Java dependencies and identify replacement or upgrade route
SAP BW Reporting dependency and data model complexity Which BW reports, extractors and integrations remain business critical? Segment reports into retire, remediate, migrate or modernise
SAP BW on HANA Performance and sizing risk during upgrade or migration Are HANA sizing, data growth and reporting concurrency understood? Validate sizing, housekeeping and performance baseline
SAP Enterprise Portal Portal customisation and authentication complexity Which applications still require Portal access and which can move to newer UX patterns? Create replacement plan for high-use applications before platform change
SAP PI/PO Hidden integration dependency and certificate risk Which interfaces are still active, externally connected or business critical? Inventory interfaces and rank by cutover risk
SAP Process Integration adapters Third-party adapter, certificate or protocol dependency Which adapters rely on unsupported versions, certificates or partner endpoints? Validate adapter support and renewal plan before upgrade
SAP Solution Manager Operational monitoring and change-control dependency Which operational processes still rely on Solution Manager? Separate monitoring, transport, ChaRM and alerting requirements
Custom ABAP Bespoke code and modification risk Which custom objects are business critical or incompatible with the target release? Run code analysis and remediate high-risk objects
Authentication and SSO Legacy authentication, certificates and identity integration Which users and applications depend on SSO, LDAP, SAML or certificates? Validate identity flows before technical upgrade
Batch and scheduling Critical jobs hidden in old scheduling patterns Which batch chains, extractors and interfaces have business cut-off times? Document batch windows and cutover sequencing
Data retention Archive, reporting and audit obligations Which data must remain accessible after upgrade, migration or retirement? Define retention, archive and read-only access plan
Infrastructure layer Unsupported OS, database or virtualisation stack Are infrastructure dependencies blocking SAP upgrade or cloud migration? Validate compatibility and plan parallel infrastructure remediation
High availability Unsupported clustering or unclear failover design Does the current HA design meet business expectations and target-platform support? Validate HA approach and failover test evidence
Disaster recovery Untested recovery or outdated recovery documentation When was recovery last tested and did it meet RTO/RPO? Run or schedule a recovery test before migration decision
Security and compliance Audit gaps caused by unsupported components Which systems carry sensitive data or regulated business processes? Prioritise unsupported systems with compliance exposure
Operational ownership Unclear basis, infrastructure and application-team responsibility Who owns remediation, testing, cutover and post-go-live support? Assign owners and decision dates for each component
Executive decision Support-risk decision not connected to business priority Which systems justify investment, migration, replacement or retirement? Create a decision matrix with owner, deadline and funding route
SAP on AWS

SAP on AWS Migration Readiness Checklist

Review landscape inventory, HANA sizing, integrations, recovery, security, operations and cutover before delivery waves begin.

18 planning rows 3.7 KB Updated 2026-06-29
Preview planning questions
readiness area evidence to confirm risk if missing next action
Business case Migration drivers, cost model, risk reduction goals and executive sponsor Programme loses direction or funding before migration waves complete Document target outcomes and funding assumptions
SAP landscape inventory System IDs, tiers, databases, interfaces, batch schedules and business owners Scope gaps cause migration wave failure or unplanned downtime Build a complete SAP system and dependency inventory
Version and support status SAP release, kernel, database, OS and add-on support position Unsupported components block migration or increase audit risk Confirm supported target combinations and remediation path
HANA and database sizing Current database sizes, growth rates, memory requirements and performance baselines Undersized targets create performance and cost issues Validate target instance families and storage layouts
Application dependencies Connected SAP and non-SAP systems, middleware, files, jobs and reporting dependencies Interfaces fail after migration due to missed dependencies Create dependency map and integration runbook
Integration readiness Inbound and outbound interfaces, certificates, firewall rules and partner connections External connections fail during cutover Create integration test and cutover validation list
High availability and disaster recovery RTO, RPO, clustering approach, backup strategy and recovery test history Migration design may not meet business continuity expectations Design HA/DR before production cutover planning
Backup and restore Backup schedule, retention, encryption, restore-test evidence and ownership Recovery assumptions remain untested until an incident Run restore tests and document recovery evidence
Security model Identity, privileged access, encryption, audit logging and compliance requirements Security exceptions appear late in the programme Map SAP security controls to AWS landing-zone guardrails
Landing zone dependency AWS accounts, networking, logging, security services and IAM roles needed by SAP SAP migration waits for foundation decisions Confirm landing-zone readiness before SAP wave planning
Network and connectivity Latency, bandwidth, DNS, routing, Direct Connect or VPN requirements Performance and cutover windows become unpredictable Validate network design and migration bandwidth
Operations readiness Monitoring, patching, alerting, basis support and escalation routes Teams cannot operate migrated SAP reliably Define runbooks and ownership before go-live
Licensing and commercial SAP, database, OS and third-party licensing assumptions Unexpected commercial constraints delay or change target architecture Complete licensing and contract review
Migration tooling SUM, DMO, backup/restore, replication, AWS tooling or partner tooling decisions Cutover approach depends on untested tooling Run tooling proof of concept and capture timings
Test strategy Technical, integration, performance, security and user acceptance test coverage Defects surface during production cutover Build test plan and acceptance criteria for each wave
Cutover planning Downtime window, rehearsal results, migration tooling and rollback route Production go-live depends on untested assumptions Run technical and business cutover rehearsals
Post-go-live support Hypercare staffing, monitoring thresholds, rollback criteria and incident process Issues are found but not owned after go-live Define hypercare model and escalation process
Optimisation roadmap Cost, performance, automation and resilience improvements after migration Migration ends at rehost and misses cloud benefits Create 30/60/90-day optimisation backlog
Oracle modernisation

Oracle Platform Modernisation Decision Guide

Compare rehost, replatform, modernise, retain, retire and phased transition routes for Oracle estates.

18 planning rows 5.0 KB Updated 2026-06-29
Preview planning questions
route best fit primary risks decision questions next action
Rehost Oracle workloads Stable systems needing infrastructure refresh or data centre exit Technical debt may move without improving operations Can the workload run safely with minimal application change? Confirm platform compatibility and operational requirements
Rehost on AWS EC2 Oracle workloads requiring full operating system or database control Licensing, patching and operational responsibility remain with the customer Which Oracle features, agents and OS dependencies require self-managed infrastructure? Validate licensing, sizing, HA, backup and support model
Replatform to Amazon RDS for Oracle Workloads where managed patching, backup and monitoring reduce operational burden Feature limitations, version constraints and licensing model mismatch Are the required Oracle features supported by RDS for Oracle? Complete feature compatibility and performance assessment
Replatform to Oracle Database@AWS Exadata-dependent or Oracle-cloud-integrated workloads that need close AWS integration Commercial complexity, regional availability and operating-model changes Does the workload need Exadata, RAC-like patterns or Oracle-managed infrastructure? Compare Oracle Database@AWS against EC2, RDS, OCI and retain options
Modernise to Aurora/PostgreSQL Applications where Oracle licensing cost and feature lock-in are strategic constraints Schema conversion, application rewrite and testing complexity Which schemas, PL/SQL packages and application behaviours require remediation? Run schema conversion assessment and migration spike
Refactor application architecture Applications needing resilience, release speed, scalability or product-change improvement Higher delivery effort and wider business change Which parts of the application constrain business outcomes most? Prioritise bounded modernisation around business value
Hybrid transition Platforms that must move in phases because of integrations, downtime or risk Extended dual-running cost and operational complexity Which dependencies force phased migration and how long can dual-running be tolerated? Define transition architecture and exit criteria
Retain temporarily Systems with contractual, technical or timing constraints Delayed action can increase support and continuity risk What explicit trigger will reopen the decision? Document retention reason, owner and review date
Retire or consolidate Low-use systems, duplicated platforms or obsolete reporting Hidden dependencies may be missed Who consumes the service and what breaks if it disappears? Validate consumers before decommission planning
Licensing review Any Oracle route where processor, core, BYOL or contract terms affect cost and risk Unplanned licensing exposure or incorrect cloud assumptions What licenses are owned, portable, restricted or tied to support terms? Complete licensing review before committing to a target platform
Performance baseline Any route involving database movement or platform change Target sizing can miss real workload peaks and batch windows What do AWR, ASH, storage, network and batch metrics show? Capture baselines before sizing and migration rehearsals
Data migration strategy Large, regulated or low-downtime Oracle estates Cutover failure, data loss, reconciliation gaps Is the migration offline, near-zero downtime, logical, physical or phased? Select tooling and run reconciliation rehearsal
Integration mapping Applications with upstream, downstream or file-based integrations Missed dependencies can block cutover or corrupt processes Which applications, reports, jobs and partners exchange data with Oracle? Build an integration dependency map and cutover checklist
Backup and recovery Business-critical Oracle systems Recovery design may not meet business continuity expectations What RPO, RTO, retention and restore-test evidence is required? Design backup, restore and DR tests before migration
Security-led remediation Systems with audit, access or patching concerns Security work may be isolated from platform strategy Which risks must be removed regardless of hosting location? Link remediation work to the platform roadmap
Operating model Teams moving from self-managed Oracle to managed or cloud-hosted services Responsibilities can become unclear after migration Who owns patching, monitoring, tuning, backups and incident response? Create a post-migration RACI and runbook set
Cost governance Oracle estates with high infrastructure, support or license cost Savings assumptions may not survive real utilisation and support constraints Which costs are infrastructure, license, support, people and risk costs? Build a total-cost model with migration and steady-state views
Decision gate Any route before funding or architecture approval Teams proceed without evidence or explicit trade-offs Which route is recommended, which route is rejected and why? Record decision, assumptions, owner and review date
Cloud risk monitoring

Cloud Risk Monitoring Readiness Checklist

Review account coverage, finding ownership, review cadence, exception handling and governance evidence before relying on risk monitoring.

18 planning rows 3.7 KB Updated 2026-07-03
Preview planning questions
area planning question evidence or decision next action
Business objective Which security, compliance or operational risk outcomes should cloud monitoring support? Risk register, audit requirements, executive reporting needs Document the monitoring outcomes before onboarding AWS accounts
Account scope Which AWS accounts, organizational units and regions should be monitored first? AWS account inventory, Organizations structure, region usage Define initial monitoring scope and expansion phases
Security services Are AWS Security Hub, GuardDuty, Inspector and IAM Access Analyzer enabled where required? Service enablement report, delegated administrator settings Confirm service coverage before relying on aggregated findings
Finding ownership Who owns triage for critical, high and medium findings? RACI matrix, security operations process, escalation rota Assign finding ownership and escalation paths
Read-only access Which IAM role will Cloudwrxs assume and which permissions are allowed? IAM role policy, External ID, trust relationship Create and review the read-only cross-account access model
External ID How will External ID protection be generated, stored and rotated if needed? Vendor onboarding record, IAM trust policy Record External ID handling in the onboarding runbook
Data visibility What security finding data can be viewed, exported or reported? Data classification, reporting requirements, privacy review Confirm what monitoring data is acceptable for operational reporting
Finding severity How should native AWS severity levels map to business priority? Severity mapping, service criticality tiers, SLAs Create a severity-to-action matrix for response teams
Exception process How will accepted risks, false positives and compensating controls be recorded? Exception register, approval workflow, expiry dates Define exception review and expiry process
Alert routing Which teams should receive alerts for account, workload or service-specific findings? Notification channels, ticket queues, team ownership map Map alert routes before go-live
Executive reporting Which metrics should be visible to leadership or risk committees? Board reporting template, audit metrics, trend requirements Agree reporting cadence and executive summary fields
Technical reporting Which details do engineers need for remediation? Finding examples, resource metadata, remediation notes Confirm technical report fields and evidence requirements
Multi-account model How should monitoring behave across standalone accounts and AWS Organizations? Organization design, delegated admin model, account tags Define organization-wide and standalone onboarding patterns
Integration needs Should findings be exported to ticketing, SIEM or reporting platforms? Integration list, API requirements, operational workflow Prioritize integrations after initial monitoring visibility is proven
Response workflow What happens when a high-risk finding is detected? Incident response playbook, escalation contacts, SLA targets Test the response workflow with sample findings
Marketplace subscription Who owns AWS Marketplace subscription, renewal and commercial approval? Procurement owner, AWS Marketplace private offer status Confirm commercial owner and subscription process
Go-live criteria What must be true before monitoring is considered operational? Access validation, sample reports, triage ownership, reporting sign-off Run a go-live review before moving to steady-state monitoring
Continuous improvement How often will findings, exceptions and coverage gaps be reviewed? Monthly review agenda, KPI trend, remediation backlog Schedule recurring risk monitoring reviews
Well-Architected review

Well-Architected Review Readiness Checklist

Collect workload scope, evidence, owners, remediation priorities and retest plans before the review turns into delivery work.

18 planning rows 3.6 KB Updated 2026-07-03
Preview planning questions
area planning question evidence to collect owner recommended action
Workload scope Which workloads and accounts are included in the Well-Architected review? Account list workload names environments regions and business owners Cloud platform owner Confirm scope before interviews begin
Business context Which business services depend on the workloads in scope? Service catalogue revenue impact users and operating hours Service owner Map technical findings to business risk
Operational ownership Who owns each finding after the review? RACI model service ownership runbook ownership and escalation paths Operations lead Assign owners before remediation planning
Reliability baseline What availability and recovery targets are expected? RTO RPO SLA SLO dependency map and previous incident data Application owner Compare design evidence against target outcomes
Security baseline Which preventive and detective controls are already active? IAM model logging coverage Security Hub GuardDuty Inspector and Access Analyzer evidence Security owner Identify gaps before remediation work is sized
Cost baseline Which workloads need cost and usage evidence? Cost allocation tags budgets rightsizing history and savings-plan coverage FinOps owner Connect cost findings to accountable teams
Performance baseline Which services need capacity or performance evidence? Metrics dashboards scaling policies latency data and known bottlenecks Platform engineer Collect evidence before review workshops
Sustainability baseline Which workloads have utilization or lifecycle concerns? Utilization trends storage lifecycle policies and idle resource reports Platform engineer Include sustainability actions where measurable
Logging and observability Are logs metrics and traces sufficient for review evidence? CloudTrail CloudWatch log groups alarms dashboards and SIEM integrations Observability owner Close visibility gaps before findings are finalized
Identity and access How is privileged access reviewed? IAM Identity Center roles permission boundaries break-glass process and review cadence Security owner Document access-review evidence
Network design Which network paths and controls support the architecture? VPC design routing security groups firewalls endpoints and ingress/egress controls Network owner Validate network evidence against workload criticality
Backup and recovery How are backups tested and evidenced? Backup policies restore-test records DR runbooks and recovery reports Operations lead Run or schedule restore evidence collection
Change management How are architecture changes governed? CI/CD controls change records approval flow and rollback evidence Engineering lead Link review findings to change process
Incident response How are incidents detected escalated and reviewed? Incident runbooks alert routing post-incident reports and on-call schedules Operations lead Confirm incident evidence before remediation planning
Remediation planning How will findings be prioritised after the review? Risk scoring effort estimate dependencies and delivery owner Programme owner Convert findings into a sequenced remediation backlog
Executive reporting What summary view is needed for stakeholders? Risk summary business impact timeline owner and decision requests Executive sponsor Prepare an executive-ready findings summary
Retest cadence When will remediated findings be rechecked? Target dates retest owner acceptance criteria and evidence repository Programme owner Schedule follow-up review checkpoints
Continuous improvement How will lessons feed into platform standards? Updated patterns guardrails templates runbooks and enablement material Cloud centre of excellence Turn repeated findings into reusable standards
Assessment readiness

Cloud Assessment Readiness Checklist

Gather business goals, scope, risks, evidence, owners and decision criteria before a cloud, data or platform assessment begins.

18 planning rows 4.0 KB Updated 2026-07-04
Preview planning questions
area planning question evidence to collect owner recommended action
Business objective What decision should the assessment support? Business goals success measures constraints and target dates Executive sponsor Confirm the assessment outcome before workshops begin
Stakeholder map Who needs to contribute evidence or approve recommendations? Sponsor platform owner security lead operations lead finance lead and application owners Programme owner Create a named stakeholder list before discovery
Current-state scope Which systems platforms accounts and regions are included? Application list cloud accounts subscriptions regions environments and ownership records Cloud platform owner Lock scope before evidence collection expands
Risk drivers Which risks are forcing the assessment now? Audit findings incidents support deadlines cost pressure resilience gaps or growth plans Risk owner Rank the drivers by urgency and business impact
Operational pain points Where are teams losing time or confidence today? Incident records manual processes escalation notes unresolved defects and service desk trends Operations lead Turn pain points into measurable assessment questions
Security evidence Which security controls are already documented? Identity model logging coverage vulnerability data network controls and exception records Security lead Collect control evidence before interviews
Resilience evidence What recovery targets and dependency maps exist? RTO RPO backup evidence failover design dependency diagrams and test history Application owner Compare recovery evidence against business expectations
Cost baseline What spend and usage data is available? Cloud bills reserved commitment data tagging coverage utilisation reports and forecast assumptions FinOps owner Establish a baseline before recommending optimisation
Data and integration Which data flows and integrations affect the recommendation? Interface catalogue batch jobs APIs data ownership latency and compliance requirements Integration owner Map critical dependencies before option scoring
Platform readiness Which foundation capabilities are already in place? Landing zone design network model IAM guardrails monitoring backup and deployment patterns Platform owner Separate foundation gaps from workload-specific actions
Skills and operating model Which teams will run the future state? Role descriptions support model skills gaps runbooks escalation paths and vendor responsibilities Operations lead Identify ownership gaps before roadmap sign-off
Compliance requirements Which regulatory or contractual constraints apply? Policy documents audit obligations residency requirements retention rules and customer commitments Compliance owner Translate constraints into assessment criteria
Application prioritisation Which workloads should be assessed first? Business criticality lifecycle status change demand complexity and dependency risk Portfolio owner Create a first-wave shortlist with clear rationale
Option criteria How will recommendations be compared? Cost risk complexity speed resilience security and business value scoring criteria Assessment lead Agree scoring criteria before options are debated
Quick wins Which improvements can be made without major transformation? Backlog items configuration gaps monitoring gaps automation candidates and documentation fixes Delivery lead Separate quick wins from strategic recommendations
Roadmap evidence What is needed to turn findings into delivery work? Recommendation owner effort estimate dependency list acceptance criteria and sequencing constraints Programme owner Convert findings into an owned roadmap
Executive reporting What summary will leaders need after the assessment? Decision summary risk heatmap investment options benefits assumptions and next-step owners Executive sponsor Prepare the reporting format before final playback
Follow-up cadence How will progress be reviewed after the assessment? Review dates success metrics action tracker owner updates and escalation route Programme owner Schedule the first follow-up before closing the assessment
Resource usage

Frequently asked questions about the planning library

Short answers that help teams and publishers understand how to use or reference Cloudwrxs planning resources.

Who should use the Cloudwrxs planning resource library?

The library is designed for cloud architecture, platform, SAP, Oracle, security and governance teams that need to turn early planning into clear questions and shareable evidence.

Can the resources be downloaded and shared internally?

Yes. Each resource is available as a free CSV download that can be used in workshops, discovery meetings, risk reviews or assessment preparation.

What planning areas do the resources cover?

The resources cover AWS landing zones, SAP on AWS migration, SAP NetWeaver support, Oracle modernisation, cloud risk monitoring, Well-Architected reviews and assessment readiness.

How should this library be cited in an article or guide?

Reference it as the Cloudwrxs Planning Resource Library with a link to this page, or use the citation text provided near the bottom of the page.

For reference and citation

Cite the resource library in planning guides or articles

Use this short reference when citing the Cloudwrxs library or sharing it with planning teams.

Cloudwrxs. Cloudwrxs Planning Resource Library. Updated 2026-07-04. Available at: https://cloudwrxs.com/cloud-planning-resources/