Question 1

How do you recognize it?

Accepted Answer

A client asks for a deployment target or audit trail the standard pipeline cannot produce, and the account team starts quoting a rebuild instead of a configuration change. Release cadence for one retainer client drops from daily to weekly while the rest of the portfolio stays on schedule, because that account now needs manual approval gates bolted onto an automated flow. Engineers describe the pipeline as 'the way we do things' rather than as a choice, and nobody can name the last time the stack was evaluated against alternatives. Onboarding a new client takes longer each quarter even though the automation surface has not changed, because exceptions are accumulating as undocumented overrides. Two clients on the same retainer tier receive visibly different delivery speeds, and the slower one is the one with stricter data residency or change-control requirements.

Question 2

Why does it happen?

Accepted Answer

The agency standardized on one deployment and orchestration stack to win on speed, then treated that decision as permanent rather than as a default with an exit path. DeployHQ-style Git-triggered deploys and Railway-style zero-config environments both optimize for a specific shape of application, and neither was chosen with multi-cloud or on-premises compliance in mind. Compliance and residency requirements arrive after the retainer is signed, not during scoping. A client in a regulated vertical may need workloads to stay inside a named region or a private environment, which a managed multi-tenant control plane cannot always satisfy without re-architecture. The automation layer was never separated from the hosting layer. When provisioning, secrets, and release logic live inside one vendor's panel, swapping the hosting provider means rebuilding the release process too, so the switching cost is quoted as a project rather than an afternoon. Nobody owns the exit criteria. Teams track uptime and deploy frequency but never track portability metrics such as how many steps are vendor-specific or how long a migration would take, so lock-in is invisible until it is expensive.

Question 3

How do you fix it?

Accepted Answer

Inventory every client account against its actual compliance constraints, then flag the accounts where the current stack cannot meet a stated requirement. Do this before the next renewal conversation, not after. Write down the migration path for one representative client, including which steps are vendor-specific and which are portable. If the estimate exceeds two weeks of engineering time, that is the real cost of the standard stack and it belongs in pricing. Introduce a thin abstraction for the parts most likely to need portability: secrets handling, environment configuration, and release triggers. Tools like systemg, which composes multi-service deployments from a single YAML manifest, show that the orchestration layer can be kept separate from the hosting layer. For accounts with hard residency or change-control needs, price a dedicated environment from the start rather than absorbing the exception into the standard retainer. FeatureFlags.app's cloud-agnostic model, deployable on Azure, AWS, GCP, or on-premises, is the kind of option to keep in the comparison set when scoping those clients.

More for DevOps Automation