Pull-Based Migration
Migrating a legacy system by making every new feature/fix/enhancement build the new-architecture path instead of touching the old one, so migration is funded and executed as a byproduct of ordinary roadmap work rather than a dedicated program — trading a per-story cost tax for the absence of a capital migration ask.
Also known as: hard-stop rule, side-effect migration, no-budget migration
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices Prashanth Pasham · 2026-07-28 | Pull-based migration | A migration where each product-driven code change carves its own domain service, so migration progress is 'pulled' by ordinary roadmap demand rather than 'pushed' by a dedicated program running on its own timeline and budget. |
| The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices Prashanth Pasham · 2026-07-28 | Hard-stop rule | The title's name for the governing decision: stop modifying the monolith entirely, with no exceptions, so that every future change is forced to become a new domain service. |
Documents (1)
- The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices Prashanth Pasham · 2026-07-28 source ↗ Reader 🖥️
By imposing an absolute rule -- never modify the legacy HCM monoliths again, only add new domain microservices -- and pairing it with three platform investments (self-service provisioning, an API-gateway routing seam, and a cached feature-flag rollback layer) that keep the resulting per-story cost tax affordable, a team can fund and execute a full monolith-to-microservices migration as a side effect of ordinary roadmap work, with no dedicated migration budget or program.
Propositions touching this concept (2)
By publication month, oldest first (extraction month when no publication date is known).
2026-07
- explicitPull-based migration is viable in production only when three platform investments are in place: self-service provisioning, an API gateway acting as a routing seam between old and new implementations, and a cached feature-flag layer supporting both gradual rollout and near-instant rollback.
- implicitBecause the upfront-tax metric is monitored continuously and used as a go/no-go signal, the pull-based migration model is designed to be self-correcting: a material drift above the expected 4-6 hour range would have triggered a pause to investigate the platform rather than being absorbed silently indefinitely.
Open gaps (3)
- incompleteThe binary 'migrated' metric requires 100% of traffic for 30+ days, but the article never addresses what happens when a fraction of traffic must legitimately stay on the monolith forever (e.g. an old partner integration that will never be upgraded) -- is that endpoint simply never declared migrated, indefinitely, with no path to closing it out?The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Look for practitioner writing on managing the migration 'long tail' of clients who cannot upgrade -- API deprecation and sunset strategy literature -- to see how others resolve the tension between a strict binary completion metric and an unmigratable minority of traffic.
- incompleteBoth headline numbers -- the ~70% peak-cost savings and the ~50% (4-to-6-hour) upfront tax -- are presented as stable constants across five years, but cloud pricing, wages, and story complexity plausibly shifted substantially between 2021 and 2026; the article gives no methodology or time series, only single-point averages, so a reader cannot tell whether either ratio actually held steady or drifted.The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Look for any published time-series cost or velocity data from Paycor/Paychex, or for other companies' cost-optimization case studies with longitudinal tracking, to see whether single anecdotal ratios of this kind are durable enough to reuse as planning assumptions.
- incompleteThe piece prescribes migrating in complete units with the old path fully deleted, but never addresses what happens to code that simply never receives a feature or fix request — the 'cold corners' that a pull-based/strangler-style migration explicitly concedes stay unmigrated. Without some forcing mechanism, complete-unit migration may structurally never reach large parts of a sprawling brownfield system.Brownfield Agentic Engineering — read next: Compare against pull-based/strangler-fig migration models and how they handle (or accept) permanently-unmigrated cold corners.