Scaling Change Across Engineering: How Concise Helped Arrive Automate a Fleet-Wide ECR Migration and Save 1,000+ Developer Hours

Engineering organizations grow fast — and with growth comes complexity. What should be a simple change, like switching container registries, can become a fleet-wide challenge involving dozens of services, edge cases, and risks. In this case study, we show how Concise partnered with Arrive (ex EasyPark) to automate a high-stakes migration, saving over 1,000 developer hours and strengthening the foundation for future platform scale.

Overview

As engineering organizations grow, complexity doesn’t just add up — it compounds. When a change needs to happen across dozens of services, the manual effort, coordination overhead, and risk can grind momentum to a halt.

In collaboration with Arrive, Concise helped deliver a fleet-wide container registry migration. At that moment, Arrive faced a high-stakes challenge: a change to its container registry was necessary to avoid production risks, but implementing it manually across dozens of microservices could have tied up hundreds of developer days and possibly delayed other projects. We helped to carry out an automated migration — saving over €100,000 worth of developer time, avoiding service downtime, and freeing teams to keep delivering customer value. Simply put in numbers:

  • Automated 88 pull requests
  • Saved over 1,000 hours of developer time
  • Improved platform consistency and long-term maintainability

This case study explores how the project was executed, what we learned, and how similar organizations can benefit from fleet-first, platform-minded engineering strategies.

The Problem: A Growing Platform and Hidden Complexity

Arrive’s developer productivity team was facing a common challenge:

The platform had outgrown its original structure, and ECR image management was decentralized, inconsistent, and fragile.

Teams used different patterns, tags, and deployment tools. In some cases, too naive image cleanup policies risked production images being deleted — with real-world consequences (like downtime caused by auto-cleaned images). 

What should have been a simple change — switching to a centralized ECR management account — became a fleet-wide dependency. Dozens of services, configurations, and edge cases needed to be handled correctly.

The Solution: Think in Fleets, Automate with Precision

Rather than placing the burden on every product team, Arrive partnered with Concise to treat this migration as a fleet-wide platform operation, not a team-by-team task.

We used a structured, product-like approach:

  • Automated 88 PRs using internal tooling and templates
  • Encoded logic for safe tagging and ECR lifecycle cleanup
  • Flagged and managed edge cases (e.g. non-standard deployment setups)

Everything was verified in CI, minimal manual input was required from developers, and no teams were blocked or derailed.

Kristjan Ulst, who’s leading Developer Productivity & Engineering Excellence at Arrive project, concluded the preparation process and existence of “Plan B” as:

The preparation was all about getting the details right before touching any code. We spent time mapping out the fleet, identifying edge cases, and running dry-runs to gain confidence that the automation would work safely across every service. A manual fallback plan always existed in theory, but given the scale, it would have been painfully slow and error-prone. That made investing in a robust automated approach not just preferable, but really the only sensible option.

– Kristjan Ulst

The Impact: Measurable, Not Just Theoretical

According to DORA and LinearB benchmarks, the average cycle time per PR is ~24 hours. By automating these 88 PRs, we avoided ~2,100 hours of manual work.

Even conservatively estimating ~50–60% of this effort as saved through automation, that still amounts to:

  • 1,050–1,300 hours saved
  • 130–160 developer days
  • €100,000+ in productivity gains

But more than that — no one outside the platform team needed to worry about it. That’s what good platform work feels like. How do they now think about future migrations, Kristjan says:

This project showed us that migrations don’t have to be painful if you treat them like a product rollout rather than a series of ad-hoc tasks. By investing in automation, we not only saved time but also reduced the cognitive load for dozens of teams, which is just as valuable. Going forward, we now think “fleet-first” by default—if something affects many services, the question is always: how do we automate it once and scale it, instead of repeating the same work manually?

– Kristjan Ulst

And what could better describe a successful project than the CEO of Arrive praising it to the world:

Use Cases: When Should You Use This Approach?

This pattern applies to more than ECR:

  • Policy rollouts: Enforcing encryption, tagging, or security policies across services
  • Version upgrades: Migrating shared libraries, container bases, or CI templates
  • Infra shifts: Moving between cloud accounts, resource types, or platforms (e.g. EKS to ECS)
  • Repo cleanups: Identifying and decommissioning unused services across the fleet

In each case, you have three options:

  • Ask every team to do the work (slow, error-prone)
  • Do it manually as a platform team (not scalable)
  • Automate it once and run it across the fleet (our approach)

Key Takeaways: A Fleet-First DevEx Operating Model

The migration succeeded because of a strong DevEx mindset. We followed three principles every platform team can benefit from:

1. Think in fleets

Design tools and migrations for many, not one. Enable repeatability and visibility across all services.

2. Treat infrastructure as a product

Provide good defaults, documentation, and automation. Platform is not just tools—it’s a user-facing product.

3. Scale change like a platform

Don’t just build new things—own the rollout, adoption, and retirement lifecycle. Change isn’t valuable unless it’s adopted.

:spanner: What’s Next?

This success is a strong foundation for platform maturity at Arrive. Future opportunities include:

  • Self-service migration tooling for other platform updates 
  • Policy-as-code integrations for compliance and lifecycle automation 
  • Automated detection of repo sprawl and drift (e.g., stale services, misaligned configs)

:handshake: Who Can Benefit?

If your company is:

  • Scaling fast with a growing microservice architecture
  • Operating across multiple teams or product areas
  • Investing in platform engineering or internal developer platforms (IDPs)
  • Facing friction rolling out org-wide infra or security changes

Then a fleet-first migration model and a partner like Concise can help you move faster, safer, and with less disruption. 

The bottom line is, if scaling changes across your engineering organization feels slow, risky, or disruptive, you’re paying for it in lost productivity and missed opportunities!

:megaphone: About Concise

Concise is a technology consultancy specializing in platform engineering, developer experience, and internal tooling strategy. We help companies like Arrive scale their engineering capabilities by solving the hard problems behind the scenes.

Want to future-proof your platform or plan your next migration? Concise helps you turn high-impact changes into seamless, automated rollouts.

Let’s talk → hello@concise.eu

Take a Look at Our Blog:
Find Your Next Read

See our list of satisfied clients.

Insurtech: an untapped competitive advantage in the insurance sector
What are the future trends in the field? What should insurance companies do today? And how will artificial intelligence affect all of this? Hannu Kikkas, the Head of Business Development at Concise, talks about the obstacles, opportunities, and threats of insurtech.
Concise legend Priit Pihus: why curiosity is the most important tool for developers and will AI take their jobs?
Priit believes that the most important quality in a developer’s career is curiosity. “If you don’t have that spark, it’s very difficult to be a great developer.” He himself has always been open to new challenges and accepts projects purely based on gut feeling and enthusiasm. “Projects find me because I can’t say “no”. I want to know what’s inside, maybe something can be improved, or maybe it’s the next big thing. I’m such a hopeless optimist and always very curious.”
Naturalistic Decision Making: the magic of learning fast
A short overview of Naturalistic Decision Making, and how we put this into practice with our Team and the Tech Lead Workgroup.
Contact

Get in touch with us!

Contact us to get quick insights, how could our partneship support your growth or eliminate challenges.