Drawing service boundaries is the easy part of a monolith migration. The hard part is that ten "separate" services still read the same tables, so you've built a distributed monolith with network latency added. Teams find this out about a year in, which is roughly when the source article's enterprise average of 18 to 36 months starts to feel real.
Brocoders wrote the source list, put itself first, and said so in the intro. This version doesn't rank anyone. It reads the same six entries through one question: what evidence does each vendor publish about changing a running system without stopping it?
How the shortlist was built
The source uses a four-criterion Migration Partner Matrix, with no numeric scores:
- Delivery proof: a named case with before and after metrics.
- Architecture ownership: does the vendor design the system, or implement your spec?
- Speed to outcome: real timelines, not slideware.
- Post-migration continuity: do they stay to evolve what they split?
One caveat before the list. Only five of the six are companies. The sixth is an individual advisor, and none of the six publishes downtime or latency figures.
The pattern to ask about: a routing facade with shadow reads
Whatever the vendor calls it, an incremental migration needs one place that decides, per route, whether the monolith or the new service answers. Shadowing lets you compare behavior before any user depends on it:
async function route(req) {
const rule = routes.match(req.path);
if (rule.target === "legacy") return legacy.handle(req);
if (rule.shadow && req.method === "GET") { // reads only, never shadow writes
const [old, next] = await Promise.all([legacy.handle(req), service.handle(req)]);
recordDiff(req, old, next); // mismatches are the migration backlog
return old; // users still get the legacy answer
}
return inBucket(req.userId, rule.percent) // gradual cutover, per-user stable
? service.handle(req)
: legacy.handle(req);
}
Three details matter. The diff log turns "we think it's equivalent" into a number. Bucketing by user keeps one person from flipping between implementations mid-session. And rollback is changing percent to 0, not a redeploy. A vendor who can't describe their version of this has probably not done a live cutover.
Six entries
1. Brocoders
Stack: Go, Node.js, React, AWS (Lambda, RDS, EC2), Docker, CI/CD
Best for: mid-market B2B teams that want one vendor to design and execute
Tallinn, 2014, 100+ engineers per the source, $35 to $50/hr, $50,000+ minimum.
Technical note: the headline case is Lake, a vacation rental platform whose monolith back end capped out near 500 connected properties and reached 40,000 about three months after the rebuild, with 210% more website traffic. It's a rebuild result, and the source doesn't say whether it was a microservices split or give downtime figures. Discovery comes first: architecture review, data migration mapping, CI/CD assessment, and an estimate locked before contract. Teams stay on after delivery, and the source counts 11 ongoing engagements. The disclosed gap is time zone, since New York is 5 to 7 hours behind.
2. InfraCloud
Stack: Kubernetes, Docker, Helm, Istio, Prometheus, Grafana, AWS, Azure, GCP
Best for: Kubernetes-heavy and multi-cloud platforms
Pune, about 2013, 200+ people, Clutch 5.0, CNCF Silver Member, Kubernetes Certified Service Provider.
Technical note: migrated a governance, risk, and compliance platform off a monolith across 15 regions in multi-cloud, with no figures published. The depth is infrastructure and the mesh, not application rewriting or post-launch feature work, so pair it with someone who owns the domain code.
3. Zoolatech
Stack: Java, Spring Boot, Kafka, RabbitMQ, AWS, Kubernetes, Terraform, React, PostgreSQL
Best for: retail, ecommerce, and regulated enterprise modernization
Miami, 2017, 600+ people, Clutch 4.9, $150,000+ minimum.
Technical note: moved a major US retailer's customer communication platform to event-driven microservices, with 2x faster feature deployment and 30% lower infrastructure cost, though neither number has a stated baseline. The approach is dependency analysis, then service boundaries, then strangler-pattern migration. The case is unnamed and the linked page is a services page, so ask for the real write-up.
4. N-iX
Stack: AWS first, plus Azure, GCP, Kubernetes, Docker, across Java, Node.js, Python, and .NET
Best for: large enterprises with multi-year programs
Poland and Ukraine, 2002, 2,400+ people, Clutch 4.8, $40 to $65/hr, $50,000+ minimum.
Technical note: the only entry that names API gateways and database-per-service strategies, which is the right instinct given where migrations stall. It claims 200+ cloud projects and 30+ migrations in the past year, with no figures per case. A $5M to $30M revenue company will likely find it oversized.
5. Chris Richardson / microservices.io
Stack: framework-agnostic
Best for: teams that will migrate themselves and need the patterns
Oakland, author of Microservices Patterns, training and advisory.
Technical note: not a delivery vendor, and no case studies. You still need engineers to write the code, but the pattern vocabulary here is what you'll want your team and any vendor to share.
6. Acropolium
Stack: Node.js, Python, Java, AWS, Docker, Kubernetes, PostgreSQL, MongoDB
Best for: mid-market teams wanting structured full-service delivery
Eastern Europe, 2009, 100+ people, Clutch 4.9, $40 to $60/hr, $50,000+ minimum.
Technical note: healthcare and logistics migrations, with a published migration guide. The case studies carry no before and after metrics or timelines, so speed and outcomes can't be benchmarked from public material.
Budget reference
For mid-market agency work the source gives $50,000 to $300,000+, with a discovery phase at $5,000 to $15,000. Eastern European agency rates run $35 to $65/hr. Most vendor figures here are self-reported and unverified.
Engineering checklist before you sign
- Routing facade: per-route switching between monolith and service, with rollback that is a config change.
- Shadow comparison: a diff log on reads before any cutover.
- Data ownership: each table has one owning service, and shared tables are a named exception with a date.
- Database split plan: how data moves, how long dual writes run, and how divergence is detected.
- Zero-downtime evidence: a past cutover with the downtime number stated, not "minimal disruption."
- Observability first: tracing and per-service dashboards before the first extraction.
- Contract tests between services, not only unit tests inside them.
- Continuity: who stays after the split to evolve it?
If you're evaluating vendors for a migration and want a second technical opinion on the extraction order and the data split, brocoders.com is a reasonable place to start that conversation.
Top comments (0)