5. Lifecycle Management

Recommended 4+1 Development AWS Ops Excellence Azure Ops Excellence

Purpose

Lifecycle Management describes how the solution is developed, deployed, operated, and eventually retired. It corresponds to the Development View in the 4+1 model and the operational aspects of the AWS/Azure Well-Architected Frameworks.

Sub-section	Focus	Depth
5.1 Software Development & CI/CD	Build and deploy pipelines	Recommended
5.2 Service Transition & Migration	Migration strategy and cutover	Recommended
5.3 Test Strategy	Architecturally significant testing	Recommended
5.4 Release Management	Release frequency and process	Recommended
5.5 Operations & Support	Support model and SLAs	Recommended
5.6 Resourcing & Skills	Team capability and readiness	Recommended
5.7 Service Start	Start-up sequence and dependencies	Comprehensive
5.8 Maintainability	Patching, certificates, dependencies	Recommended
5.9 Decommissioning & Legacy Removal	End-of-life and disposal	Recommended
5.10 Exit Planning	Vendor lock-in and exit strategy	Recommended

5.1 Software Development & CI/CD

Recommended

Development Practices

Does the application include any software developed internally?

• Yes - [complete the sections below]
• No - [commercial/vendor solution only]

Attribute	Detail
Source control platform	[e.g., GitHub, GitLab, Bitbucket]
CI/CD platform	[e.g., Jenkins, GitHub Actions, Azure DevOps]
Build automation	[how builds are triggered and managed]
Deployment automation	[how deployments are automated]
Test automation	[what testing is automated in the pipeline]

Application Security in Development

Control	Implementation
Security requirements identification	[how security requirements are captured]
Static Application Security Testing (SAST)	[tool used]
Dynamic Application Security Testing (DAST)	Yes / No - [tool]
Software Composition Analysis (SCA)	[tool used]
Container image scanning	[if applicable, tool used]
Secure coding practices	[standards, training, code review]
Patch management	[how security patches are applied and SLAs]

5.2 Service Transition & Migration

Recommended

Migration Classification (6 R’s)

If this solution replaces or migrates an existing system, classify the migration approach:

Classification	Selected?	Description
Retain	☐	Keep as-is, not suitable for migration at this time
Retire	☐	Decommission; functionality no longer needed
Rehost	☐	Lift-and-shift to new infrastructure with minimal changes
Replatform	☐	Lift-and-shift with targeted optimisations (e.g., managed database)
Refactor	☐	Re-architect components to take advantage of new platform capabilities
Replace	☐	Replace entirely with a new solution (e.g., SaaS product)

Transition Plan

Attribute	Detail
Deployment strategy	Big Bang / Blue-Green / Canary / Strangler Fig / Rolling / Parallel Run
Data migration mode	One-off / Phased / Continuous Sync / Not applicable
Data migration method	[e.g., Export/Import, ETL, CDC, DMS, manual]
Data volume to migrate	[e.g., 500 GB]
End-user cutover approach	One-off / Phased / Not applicable
External system cutover	One-off / Phased / Not applicable
Maximum acceptable downtime	Zero / Seconds / Minutes / Hours / Days
Rollback plan	[how to revert if the transition fails]
Acceptance criteria	[what must be true before cutover]
Transient infrastructure needed?	Yes / No — [if yes, describe temporary infrastructure required during migration]

5.3 Test Strategy

Recommended

Describe the testing approach that validates the architecture:

Test Type	Scope	Approach	Environment	Automated?
Integration testing	[what is tested]	[approach]	[environment]	Yes / No
Contract testing	[API contracts between services]	[approach]	[environment]	Yes / No
Performance testing	[load, stress, soak]	[approach]	[environment]	Yes / No
Security testing	[penetration, vulnerability]	[approach]	[environment]	Yes / No
DR testing	[failover, recovery]	[approach and frequency]	[environment]	Yes / No

Guidance

This section covers architecturally significant testing — not unit tests or functional test cases (which belong in detailed design / low-level documentation). Focus on testing that validates the architecture itself: integration points, performance characteristics, security posture, and recovery capabilities.

5.4 Release Management

Recommended

Attribute	Detail
Release frequency	[e.g., continuous, weekly, monthly, quarterly]
Release process	[how releases are planned, approved, and deployed]
Release validation	[how releases are validated in production]
Feature flags / toggles	[if used, how they are managed]

5.5 Operations & Support

Recommended

Attribute	Detail
Support model	[which teams or vendors support the application]
Support hours	[e.g., 24/7, business hours, follow-the-sun]
SLAs	[internal or external service level agreements]
Escalation paths	[how issues are escalated]

Sustainability in Operation

Recommended

Operational practices have a continuous carbon impact. Document how sustainability is preserved over the life of the running solution; the metric and tooling detail belongs in Section 4.5.

Question	Response
Are non-production environments on an auto-shutdown schedule (e.g., evenings, weekends)?	Yes / No — [schedule]
Is there a periodic review of compute right-sizing (typically quarterly)?	Yes / No — [cadence]
Are unused resources (orphaned VMs, unattached disks, idle environments) actively identified and reclaimed?	Yes / No — [process]
Is the carbon footprint reported alongside cost in operational reviews?	Yes / No
Are environment retirements (e.g., a decommissioned dev cluster) actually deleted, not just stopped?	Yes / No

5.6 Resourcing & Skills

Recommended

Assess whether the team has the skills and resources to build, operate, and support the solution.

Team Capability Assessment

Skill Area	Current Level	Action Required
Cloud platform (e.g., AWS, Azure, GCP)	High / Medium / Low / N/A	[training, hiring, or contractor needed?]
Infrastructure as Code (e.g., Terraform, Pulumi)	High / Medium / Low / N/A	[…]
CI/CD pipeline management	High / Medium / Low / N/A	[…]
Application technology stack	High / Medium / Low / N/A	[…]
Database administration	High / Medium / Low / N/A	[…]
Security & compliance	High / Medium / Low / N/A	[…]

Operational Readiness

Question	Response
Can the team fully operate and support this solution in production?	A: Fully capable / B: Partially capable / C: Not yet capable but willing to learn / D: Not capable and will not be in the foreseeable future
If B, C, or D: what additional resources are required?	[e.g., DBA, DevOps engineer, cloud architect, managed service]
Is a managed service being considered for ongoing operations?	Yes / No — [details]

5.7 Service Start

Comprehensive

Describe how the application and its supporting services are started:

[What steps are needed to bring the solution into operation? Are there manual steps? What is the start-up sequence and dependency order?]

5.8 Maintainability

Recommended

Describe how the solution design enables ongoing maintenance:

Concern	Approach
Keeping software versions current and supported	[patching strategy]
Hardware lifecycle management	[refresh cadence]
Certificate management	[renewal process]
Dependency management	[how third-party dependencies are tracked and updated]

5.9 Decommissioning & Legacy Removal

Recommended

Where this solution replaces or modifies existing systems, document the plan for removing legacy infrastructure.

Solution Lifespan

Attribute	Detail
Intended lifespan	[expected or planned lifetime of the solution]
End-of-life triggers	[what would trigger decommissioning]
Decommissioning blockers	[dependencies or constraints on retirement]

Legacy Infrastructure Removal

Legacy Component	Current State	Decommission Date	Owner	Dependencies	Status
[system/server/service]	[running / standby / powered off]	[target date]	[person/team]	[what depends on it]	Planned / In Progress / Complete

Guidance

Common items to decommission after migration or replacement:

• Servers and VMs — physical or virtual machines no longer needed
• Licences — software licences that can be released or cancelled
• Network rules — firewall rules, DNS entries, load balancer configs for retired systems
• Data stores — databases, file shares, or storage accounts (after data migration and retention period)
• Monitoring and alerting — dashboards, alerts, and runbooks for retired systems
• Service accounts and credentials — accounts and secrets for decommissioned integrations
• Documentation — update or archive architecture documents for retired systems

Technical debt is tracked in Section 6.6 — Technical Debt Register.

Data and Infrastructure Disposal

Comprehensive

Attribute	Detail
Data disposal method	[how data will be securely erased — crypto-shredding, secure wipe, physical destruction]
Data retention obligations	[any data that must be retained beyond decommissioning, and for how long]
Infrastructure disposal	[how hardware/cloud resources will be decommissioned — resource deletion, subscription cancellation, hardware return]
Cost savings realised	[expected cost reduction from decommissioning]

5.10 Exit Planning

Recommended

If hosted in public cloud or with a third-party provider:

Attribute	Detail
Exit strategy	[how to migrate away from the current provider]
Data portability	[how data can be extracted and migrated]
Vendor lock-in assessment	[degree of lock-in and mitigation]
Exit timeline estimate	[how long an exit would take]

Scoring Guidance

Score	What This Looks Like
1	CI/CD tool identified but pipeline not documented
3	Development practices, deployment strategy, support model, and release frequency documented; migration plan in place if applicable
5	All of the above plus security scanning integrated in pipeline, team skills assessed with action plan, exit strategy documented with vendor lock-in assessment