Kennedy Mutisya - The Architecture Review Checklist for Inheriting Legacy Systems

Inheriting a legacy SaaS system as a new engineering leader or principal architect is a bit like being handed the keys to a moving car while someone else is trying to change the tires. You need to keep the business running smoothly and preserve service availability while figuring out what is broken under the hood.

Before making any rash decisions to "rewrite everything" - which is often a career-ending trap - you need a cold, objective assessment of what you actually have.

This checklist is divided into four critical pillars to help you map the land, manage operational risks, and plan your next strategic moves.

1. The Stability & Risk Pillar (Weeks 1-2)

Your immediate goal is to ensure the system doesn't collapse under your watch. Focus on observability and identifying operational blind spots.

Telemetry & Observability

Centralized Logging: Are metrics, logs, and traces centralized in tools like Datadog, New Relic, or Honeycomb, or are engineers still SSH-ing into production servers to read raw log files?
Time-to-Detection (TTD): Can you accurately pinpoint the root cause of a production failure within 5 minutes?
Alerting Fidelity: Check the signal-to-noise ratio of existing alerts. If the team is plagued by constant, non-actionable Slack notifications or pager alerts, true emergencies will go unnoticed.

The Deployment Safety Net

CI/CD Pipeline Maturity: Is there a modern, automated pipeline, or is deployment a manual, stressful event handled by one or two "gatekeeper" engineers?
Rollback Speed: Can you roll back a bad deployment at the press of a button, or does a rollback require manual database surgery and code cherry-picks?
Pre-production Environments: Do staging and development environments closely mirror production, or is "testing in production" the default workflow?

Disaster Recovery (DR) Reality Check

The Restore Test: When was the last time database and file backups were actually restored and tested in an isolated sandbox?
RTO & RPO: Do you have a verified, SLA-backed Recovery Time Objective (RTO) and Recovery Point Objective (RPO)?
Single Region Vulnerabilities: Is the infrastructure confined to a single cloud provider zone or region without automatic failover?

Technical Debt & Security Vulnerabilities

Automated Dependency Auditing: Run tools like Snyk, Dependabot, or Trivy. Legacy systems are notorious for running framework versions that haven't seen a security patch in years.
Secret Management: Are production secrets, API keys, and certificates securely managed via systems like Vault or AWS Secrets Manager, or are they hardcoded in repositories?

2. The Architecture & Scale Pillar (Weeks 3-4)

Here, you are analyzing how the application handles data, traffic, and state under load.

Monolith vs. Distributed Footprint

Code Coupling: Is it a "spaghetti monolith" where changing code in the billing module unexpectedly breaks the reporting engine?
Domain Boundaries: Are domain boundaries cleanly separated, or is the business logic tightly coupled with database-specific implementations?

Data Integrity & Bottlenecks

Database Single Point of Failure (SPOF): Is the primary relational database server overwhelmed? Look for missing indexes, bloated tables, and whether the application relies heavily on database-level stored procedures, which are notoriously hard to scale, debug, and version control.
Read/Write Split: Does the system utilize read replicas to offload reporting and search traffic from the transactional primary?

State Management

Horizontal Scalability: Does the application scale horizontally, or does it rely on sticky sessions, storing session state on the local server, making true cloud elasticity and autoscaling impossible?
Caching Strategy: Is caching (Redis, Memcached) implemented as a strategic layer with proper TTLs, or is it used as a band-aid to cover up slow database queries?

API & Integration Contracts

Documentation and Compliance: Are internal and external APIs versioned and documented using standards like OpenAPI/Swagger, or are you flying blind on what upstream and downstream services expect?
Rate Limiting & Safety: Is there an API gateway enforcing rate limits to prevent malicious actors or misconfigured integration clients from taking down your API servers?

3. The Developer Velocity Pillar (Weeks 5-6)

A legacy system's worst trait isn't always its bugs; it's how much it slows your team down and destroys developer morale.

Local Environment Setup

"Time to First Hello World": Can a newly hired engineer clone the repository and get a working environment running locally, for example using Docker Compose, within a few hours, or does it take weeks of manual configuration and dependency hunting?
Mock Dependencies: Are external SaaS dependencies, such as Stripe or Twilio, cleanly mocked or sandboxed for local testing?

Test Coverage vs. Test Confidence

Flakiness Index: Don't just look at the coverage percentage. Are the tests flaky, failing intermittently in CI/CD pipelines?
Execution Time: Do developers skip running the test suite because it takes 45 minutes to execute? A slow test suite is a bypassed test suite.

Knowledge Silos & Tribal Knowledge

Runbook Availability: Is the system's runtime architecture documented in an accessible format, or does it live entirely inside the heads of the two longest-tenured engineers?
Bus Factor: If your lead developer were to leave tomorrow, would the team still be able to deploy and support the system?

4. The Financial & Legal Pillar (Ongoing)

Legacy infrastructure often hides massive, unoptimized cloud spend and compliance liabilities that drain engineering budgets.

Infrastructure Efficiency

Orphaned Resources: Are you paying for massive, over-provisioned idle servers, old database snapshots, and unattached storage volumes?
Containerization & Serverless: Can workloads be migrated to containers or serverless architectures to leverage dynamic scaling and cut cloud spend?

Data Privacy & Compliance

Encryption at Rest & In Transit: Is customer data encrypted end-to-end, or does it transit plain-text over internal networks?
Regulatory Alignment: Does the legacy architecture comply with current regulations (GDPR, CCPA, HIPAA, SOC2)? How easy is it to perform a hard delete of user data (Right to be Forgotten)?

Licensing Dead Ends

Commercial Lock-in: Are you tied to expensive, proprietary legacy database or operating system licenses? Can these be migrated to open-source alternatives like PostgreSQL or Linux?

The Assessment Matrix

To help prioritize your roadmap, run every major component of the inherited system through this quick triage matrix:

Architectural Health	Business Value	Action Plan
High (Stable / Scalable)	High (Core feature)	Maintain & Optimize - Leave it alone; it works and provides high ROI.
Low (Fragile / Slow)	High (Core feature)	Refactor / Strangler Pattern - Incrementally isolate and replace this module.
High (Stable / Scalable)	Low (Rarely used)	Contain - Minimize active investment; keep the lights on with minimal resources.
Low (Fragile / Slow)	Low (Rarely used)	Decommission - Sunset the feature entirely to reduce the maintenance surface area.

The Golden Rule of Legacy Transitions

Avoid the temptation of the "Big Bang Rewrite." It is almost always a trap that burns capital, delays feature delivery, and alienates product and sales teams.

Instead, rely on the Strangler Fig Application pattern. Chip away at the legacy system by placing new features in microservices or clean, decoupled modules behind an API gateway. Over time, routing is shifted from the legacy core to the new modules, gradually letting the old, unmaintainable code wither away.