---
title: "How Ena Pragma onboards a new maintenance client"
description: "Four phases: diagnostic, architecture, build and deploy, then ongoing operations. What happens in each, and why the order matters."
publishedAt: 2026-07-26
author: Ena Pragma
url: https://enapragma.co/blog/how-we-onboard-a-maintenance-client
tags: ["methodology", "software-maintenance"]
---

You don't hand your production systems to someone new without knowing what the first month looks like. Here's what onboarding with Ena Pragma actually involves, step by step.

## Step 1: Diagnostic

We start by finding out what's actually running, not what the documentation says is running. That means reviewing the live codebase, the infrastructure it sits on, and the processes around it: deployments, backups, who has access to what. The goal is a clear picture of the system as it exists today, including the parts nobody's touched in a while.

This step exists because assumptions about a system are usually wrong somewhere, and finding out where before we touch anything is cheaper than finding out after.

## Step 2: Architecture

Once we know what's there, we map out how it should work going forward: what needs to be stabilized first, what can wait, and where the real risk sits. This is where we flag anything that looks fragile: an unverified backup, an untested rollback path, a dependency nobody's updated. You get a plan, not a surprise.

## Step 3: Build & deploy

This is where changes actually happen: fixing what's broken, closing gaps the diagnostic surfaced, and getting the system to a state where ongoing maintenance is straightforward instead of a constant scramble. Every change goes through the same verification discipline we bring to any production work: claims about the system get checked against the system, not taken on confidence.

## Step 4: Ongoing operations

Once the system is stable, we don't leave. This is the part of the model that's different from a typical build-and-hand-off engagement: EP keeps running quality checks and monitoring loops continuously, not on a sprint schedule. If something starts drifting, we catch it before it becomes a client-facing problem.

## Why it's structured this way

Most bad handoffs happen because nobody did the diagnostic. The new team inherits a system, makes changes based on assumptions, and finds out what was actually load-bearing when something breaks. Sequencing diagnostic before architecture, and architecture before any changes ship, is the whole point. It's slower on day one and faster for every day after.