Architecture
How a Payroll Platform Migrated From 3 Monoliths to 120 Microservices Without a Budget
By treating microservices migration as a side effect of regular product development, Paycor avoided years of separate planning and funding while reaching 120 domain services in production.
InfoQ
Pull-Based Migration: A Pragmatic Path#
In 2021, engineers at Paycor (a human capital management platform later acquired by Paychex) faced a familiar problem: three sprawling, interdependent monoliths needed to be broken apart, but the business kept rejecting migration budgets in favor of revenue-generating features. Rather than waiting for funding or drafting lengthy migration plans, the team adopted a radically simpler rule: every new feature, bug fix, and enhancement would carve out its own microservice instead of modifying the monolith.
This "pull-based migration" strategy worked. Today, Paycor operates more than 120 domain microservices on Azure with zero downtime during the entire transition. The original monoliths remain only for functionality nobody has needed to revisit. The cost of the approach—roughly 50% longer development time per story—proved manageable when infrastructure could be provisioned in minutes rather than weeks.
Three Platform Foundations#
The pull-based strategy hinged on three critical infrastructure investments.
Self-service provisioning at scale: The team adopted a one-subscription-per-domain pattern on Azure. Each product area (time and attendance, payroll, reporting, integrations) got its own isolated subscription with templated infrastructure—Kubernetes namespaces, databases, message queues, key vaults, and observability tools—all instantiable in minutes. This structural choice delivered cost transparency, blast-radius isolation, and a behavioral shift: engineers were willing to absorb the 50% development tax only because standing up a new service no longer required weeks of DevOps tickets.
API Management as the routing seam: The team placed API Management (APIM) in front of every endpoint targeted for migration. Both the monolith endpoint and the new domain service could register under the same path, with traffic split controlled by deployment configuration rather than client changes. This decoupling allowed gradual cutover—testing 1% of traffic to the new service for a day, then incrementally expanding—while clients (mobile apps, partner integrations, public APIs) remained unaware of the transition.
Feature flags with Redis caching: A Redis-backed wrapper around Azure App Configuration provided instant feature toggling at production volume. Gradual rollout (enabling a flag for 1% of tenants, then expanding) combined with near-instant rollback (flipping a flag to revert a misbehaving release within seconds) became the safety net for continuous migration.
