IT transformation, architecture and migrationEvery change to your systems takes too long.

Architecture is your org chart in concrete.

We cut systems to fit your teams and see migrations through, all the way into operation.

Book an intro call

Free, 30 to 60 minutes: first ideas and an honest assessment of whether we can help.

A variant configurator instead of manual work: parts lists are generated automatically (Machinery). Read the full case

How it works

From the first call until it runs

1
First call
free, 30 to 60 minutes
You tell us where things are stuck. You get first ideas you can try right away, and an honest assessment of whether we can help you. If we can't, we tell you.
2
Measure
We measure where the work gets stuck and lay the org chart, the process map and the system landscape on top of each other. That is where we look for the cause.
3
Change it together
We change what holds the work up, in the organisation, the workflow or IT. We only leave once it runs without us.

Our approach

What can still be changed tomorrow

IT is where an organisational decision sets hard. As long as something lives in the process manual, it can be changed. Once it sits in interfaces, data models and deployment pipelines, every change costs money and nerves. That is why we make sure systems are cut at the right boundaries. And we change systems together with the ownership that built them. Otherwise the old structure pulls the new cut back. A system boundary that cuts across your teams gets worked around.

Your systems are cut along the value streams. Otherwise every delivery crosses several teams.
We break up rigid legacy structures so that your organisation can react quickly again.
We take on co-location and cloud migrations and the consolidation of IT systems after mergers, all the way into operation.
What runs by hand at your place gets automated: deployments, tests, infrastructure. That cuts lead time and makes releases boring.
We see brownfield migrations through step by step, for example with the strangler fig pattern.

References

Three examples

All the way into operation.

All references

A scaling start-up needs a different architecture from a corporation under regulatory pressure. Sometimes the right answer is the monolith. Whether it is replacing a CRM, migrating a database or moving to the cloud: we use what measurably contributes to the result. Everything else gets simplified, automated or removed.

Post-merger integration

SaaS

The bottleneck: systems built several times over. Every change had to be repeated in several stacks.

The cause: Each of the four companies had built its technology to fit its own organisation. After the merger, four architectures lived on. (IT)

Our solution: One common stack and a target architecture into which the old systems were moved step by step.

Key result

One common stack for all software development, with the old systems moved over step by step.

Read the full case

From grown systems to microservices

Broadcasting

The bottleneck: the path from the editorial team into IT development. Every new digital offering waited for changes to the grown system.

The cause: separate silos for editorial and IT development. The system landscape had grown the same way: one big block that everyone depended on. (organisation and IT)

Our solution: We brought the editorial team and IT into shared workflows and cut the system into microservices along those workflows.

Key result

A working prototype within a few days, followed by a handover to the team with extensive training.

Organisation Process IT

Read the full case

Vacating a data centre on a fixed date

Telecommunications

The bottleneck: unclear dependencies. Nobody could say for sure what could move when.

The cause: Everyone involved planned on their own. There was no shared view of systems, dependencies and the maturity of the teams. (organisation and IT)

Our solution: We created a shared current and target view of all systems and turned it into blueprints and release plans the teams could use to plan the move themselves.

Key result

Blueprints and release plans the teams used to plan the move themselves.

Process IT

Read the full case

Let's look together at where your work gets stuck.

Book an intro call

Result

Why it holds

Technology keeps working after we leave. That is why we optimise for what can still be changed in two years: clean boundaries, continuous data flows, and automation exactly where the work would otherwise go back to being manual.

Tools

Our toolkit

These are the tools we use most in IT transformation and migration. Which one we use is decided by the bottleneck.

Java, Spring Boot, Vue.js and React: For systems we build or develop further ourselves.
Docker, Kubernetes and AWS: For running in containers and in the cloud.
Camunda: Brings business processes into the software as executable workflows.
CI/CD, DevSecOps and test automation: So that releases become boring.
Microservices and service-oriented architecture: When the domain cut calls for it. Otherwise it stays a monolith.
Strangler fig pattern: Replaces old systems piece by piece while they keep running.

Industries

No industry focus

The constraints help decide which cut holds. An approval process across four levels cannot handle weekly deployments, and a fast-growing team cannot live with half-yearly releases. That is why we first ask what your system has to withstand, and only then what we build it with.

These are the industries we have worked in. Where there are references, a click takes you there.