The First 90 Days With a DevOps Partner: A Realistic Timeline

The First 90 Days With a DevOps Partner: A Realistic Timeline

Most writing about hiring a DevOps partner stops at the sales conversation. What decides whether the money was well spent is the ninety days after the contract is signed, and almost nobody writes that part down honestly.

This describes what a competent partner does in the first quarter, in what order and why, plus what your side has to provide. That second half matters: the most common reason a good engagement starts badly has nothing to do with the engineers. It is that nobody could grant access, or nobody was empowered to decide.

None of it is a guarantee. A three person startup on one AWS account moves faster than a fifty person company with four environments nobody fully understands. Treat it as the shape of the work, not a schedule you can hold anyone to.

What has to be true before day one

Five things. Miss any of them and the engagement starts slow, and you blame the wrong party.

A named decision maker. One person who can approve a change without convening a committee. When a partner finds an unencrypted database snapshot in a public bucket on day three, somebody says yes that afternoon.

Access, in writing, with a path. Read-only on day one, write access to non-production by the end of week one, production change rights when the real work starts. Access delays are the single most common cause of a slow start. If issuing a role takes your security team three weeks, fine, but start before the kickoff call, not after.

Context on the product. Not documentation, which you probably do not have. An hour with whoever knows why the system is shaped as it is: which service is fragile, what broke last quarter, which queue nobody wants to touch. That saves weeks of archaeology.

About an hour a week from your engineers. Answering questions, reviewing pull requests against your own infrastructure, confirming a change is safe. A partner who needs ten hours a week is not reducing your load.

Willingness to freeze change briefly. Somewhere in weeks five to eight, deploys pause for a few hours while a pipeline or network path is cut over. Agree in advance when that window can happen. Teams that refuse any freeze drag the cutover across a month of half-finished states, which is riskier than the freeze.

Week 1: access, discovery, and a read-only audit

Nothing changes in week one. That is deliberate. A partner who starts editing production on day two either got lucky or is about to cause an incident.

The work is inventory. Which accounts exist, what runs where, what is managed by code and what was clicked into existence, where the data lives, what the backup situation actually is rather than what the dashboard claims, who holds standing production access and whether any of them have left.

Access for this is read-only, scoped and time-bound. On AWS that means a role assumed from an external account with an external ID, carrying the managed read-only and security audit policies plus an explicit deny on secret material:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenySecretMaterialDuringAudit",
      "Effect": "Deny",
      "Action": [
        "secretsmanager:GetSecretValue",
        "ssm:GetParameter",
        "ssm:GetParameters",
        "ssm:GetParametersByPath",
        "kms:Decrypt",
        "lambda:GetFunction",
        "dynamodb:GetItem",
        "dynamodb:Query",
        "dynamodb:Scan",
        "s3:GetObject"
      ],
      "Resource": "*"
    }
  ]
}

Attach that alongside arn:aws:iam::aws:policy/ReadOnlyAccess and arn:aws:iam::aws:policy/SecurityAudit. An explicit deny beats the allows in a broad managed policy, so the auditor sees that a secret exists, who can reach it, and when it was last rotated, without reading its value or the contents of your buckets and tables. It also settles whether an outside party can read your customer data.

Week one ends with a written risk list ordered by what would hurt most if it happened tomorrow. Expect discomfort. Common entries: backups never restored, one person who is the only one able to deploy, no alert on the thing that actually pages, credentials in a repository, a certificate expiring soon, one instance holding state nobody replicated.

Done looks like: an inventory you did not have, a ranked risk list, agreement on the first three fixes.

Weeks 2 to 4: stop the bleeding

This phase is not architecture. It removes the failure modes that turn a normal Tuesday into a very bad one.

Backups that are proven, not configured. A backup you have never restored is a hypothesis. Verifying one is boring and it is the highest value hour of the quarter. For a custom-format Postgres dump, on a scratch instance, never against production:

#!/usr/bin/env bash
set -euo pipefail

SNAPSHOT="${1:?usage: verify-restore.sh <dump-file>}"
SCRATCH_DB="restore_check_$(date +%Y%m%d%H%M%S)"

createdb "$SCRATCH_DB"
trap 'dropdb --if-exists "$SCRATCH_DB"' EXIT

START=$(date +%s)
pg_restore --dbname="$SCRATCH_DB" --no-owner --exit-on-error --jobs=4 "$SNAPSHOT"
ELAPSED=$(( $(date +%s) - START ))

echo "restore completed in ${ELAPSED}s"

psql --dbname="$SCRATCH_DB" --tuples-only --command "
  SELECT 'rows_in_orders=' || count(*) FROM orders;
  SELECT 'newest_order=' || max(created_at) FROM orders;
"

That answers the two questions a green backup dashboard cannot: how long a restore takes, and how much data you would lose. If the first answer is six hours and your recovery objective is one hour, you found a real problem in week two instead of during an outage.

Alerting that corresponds to reality. Most teams arrive with either no alerts or two hundred that everyone mutes. Cut them to a small set reflecting user-visible failure, then add the two or three that were missing. Each should mean something and have an owner.

Access cleanup. Remove departed staff, replace long-lived keys with roles, put multi-factor on accounts that can spend money or delete data, move root credentials off one person's laptop.

The obvious cost items. Unattached volumes, idle load balancers, old snapshots, oversized non-production instances, logs kept forever at premium tier, environments running full size overnight. None of it needs an architectural change. Deeper savings (right-sizing under real load, commitment purchases, storage class changes) come later, once there is data to decide responsibly. Nobody can tell you the percentage in advance, and anyone who does is guessing.

Done looks like: a timed restore you watched succeed, alerts the on-call person trusts, no orphaned credentials, easy waste removed.

Weeks 5 to 8: the structural work

Now the slower work starts and progress becomes less visible. Warn stakeholders: week six feels quieter than week three.

Infrastructure as code coverage. The goal is not rewriting everything in Terraform. It is that anything you could not survive losing is described in code and can be recreated. Usually that means importing existing resources rather than replacing them, starting with networking, IAM, and data stores. Whatever is still clicked into the console is recorded as a known gap, not quietly ignored.

Pipeline hardening. Reproducible builds, pinned dependencies, no secrets in build logs, a staging deploy before production, and a rollback someone has actually executed. Rollback is the part most often skipped, and a pipeline without a tested one is a one-way door.

Environment parity. Not identical environments, which is expensive and rarely worth it. Structural parity: same deployment mechanism, same configuration shape, same runtime versions, differing only in size and data. The point is that a change tested in staging tells you something true about production.

This is where deeper problems surface. If the application keeps state on local disk, cannot run two copies at once, or opens a database connection per request with no pooling, infrastructure work does not fix it. A good partner says so and scopes it as application work instead of quietly building around it.

Done looks like: critical infrastructure reproducible from code, a tested rollback, staging that predicts production, a written list of what is still manual.

Weeks 9 to 12: handover, documentation, and proof

An engagement that leaves your team unable to operate the system alone has failed, whatever the dashboards say.

Runbooks for the incidents that actually occur. Not a generic wiki. One page per realistic failure, written so somebody woken at 3am can follow it:

title: API latency above SLO
severity: sev2
owner: platform
last_reviewed: 2026-08-12
last_tested: 2026-08-12

symptoms:
  - p95 latency above 800ms for 5 minutes
  - checkout error rate rising

first_checks:
  - dashboard: grafana/api-overview (RPS, p95, error rate)
  - recent deploys: last 60 minutes, api and worker
  - database: active connections vs max_connections

likely_causes:
  - id: bad-deploy
    check: a deploy landed within 30 minutes of the alert
    action: roll back to previous release, then investigate
  - id: connection-pool-exhaustion
    check: active connections at or near max_connections
    action: restart the worker pool, then raise limits per runbook db-pool
  - id: upstream-provider
    check: payment provider status page
    action: enable degraded checkout mode, notify support

escalate_if:
  - no improvement after 15 minutes
  - customer data may be affected
escalate_to: engineering lead, then CTO

after:
  - incident note within 24 hours
  - add the check that would have caught this earlier

The last_tested field is the one that matters. A runbook nobody has walked through is fiction.

On-call readiness. A rotation with named people, an escalation path, agreed severity levels, and a short post-incident habit. It does not need to be sophisticated, it needs to exist.

A real handover. Your engineers perform a deploy, a rollback, and a restore with the partner watching, not driving. If they cannot, the work is not finished.

Done looks like: tested runbooks, a working rotation, your team running the critical operations unaided.

The 90 day timeline at a glance

Phase	Focus	Client involvement	What "done" looks like
Week 1	Access, discovery, read-only audit, risk triage	Decision maker named, read-only access issued, an hour of product context	Inventory, ranked risk list, agreed top three fixes
Weeks 2 to 4	Backups verified, alerting fixed, access cleanup, obvious cost waste	Approvals within a day or two, write access to non-production	A timed restore observed, trusted alerts, no orphaned credentials
Weeks 5 to 8	IaC coverage, pipeline hardening, environment parity	An hour a week, code review, one agreed freeze window	Critical infrastructure in code, tested rollback, staging that predicts production
Weeks 9 to 12	Runbooks, on-call, documentation, measurement	Engineers available for handover exercises	Your team deploys, rolls back, and restores unaided

How to tell whether it is working

Judge it on observable things, not on how busy the reports look.

Deploy frequency and lead time. How often you ship, and how long a merged change waits before reaching users. Both come from git and pipeline history, so they are hard to spin. Improvement usually appears in weeks five to eight, not before.

Time to restore. How long from "something is broken" to "it works again", from real incidents where possible, drills where not.

Repeat incidents. The same failure twice means the first fix addressed a symptom. A falling repeat rate beats a falling incident count, which is easy to influence by counting fewer things.

Cost trend, with context. Absolute spend is noisy while you are growing. Look at cost per unit of what you sell, and whether spend moves with usage.

Bus factor. How many people can deploy, restore the database, and rotate a credential. If that is still one at day ninety, the engagement missed its main job.

Baseline all of these in week one. Without a baseline, every later conversation about progress is opinion.

When this does not work

Some engagements fail, and the reasons repeat.

Access never fully arrives. Read-only in week two, write access in week six, production access never. Everything stays advisory. If your process cannot grant a scoped external role, resolve that before signing, or accept that you are buying consulting rather than execution.

No decision maker. Recommendations pile up awaiting approval from someone permanently in another meeting. Ninety days pass, the audit was accurate, almost nothing shipped.

Ownership is unclear internally. Two teams each believe the other owns deployment. A partner cannot arbitrate that, only you can.

The real problem is the application. If the system cannot scale horizontally, or one database is doing work that needs a queue, infrastructure work reduces symptoms without removing the cause. An honest partner says this in week two. Rearchitecting a product is a different engagement with a different timeline.

Expectations were never written down. "Improve our DevOps" is not a scope. Three named outcomes, each with a definition of done, is. Vague briefs produce disappointing quarters even when the work was good.

Change is not permitted. A team that will not pause deploys, accept a pipeline change, or adopt new tooling has bought an auditor. That is a legitimate purchase, but it should be a conscious one.

The short version

A partner controls perhaps two thirds of the first ninety days. The rest is your access, your decisions, and an hour a week.

If you are evaluating a partner now, the useful question is not what they will build. It is what they expect from you in week one, and what they do when the answer is not more infrastructure. If you want to talk through what your own first ninety days would realistically look like, we are happy to map it out before anything is signed.