A while back, I joined an organization where I encountered a deeply chaotic system landscape. There was minimal oversight of the systems in place, their users, or their functionality. The ERP system was unreliable to the point that every reboot risked failure. Compounding the issue, the only technical support available, for the ERP system, came from a retired gentleman living in a remote Swedish forest.

Simplified overview of the initial technical architecture

This wasn’t just a technical challenge; it was a systemic issue. The organization’s federated structure, with its central federation and multiple connected and sub-federations, made uniformity nearly impossible. Over time, systems became convoluted with overlapping services, redundant APIs, and untraceable ownership of data. The result? Chaos, inefficiency, and uncertainty.

In this post, I’ll walk you through the journey of transforming that chaos into a modern, scalable platform. We’ll explore the strategies we used, the challenges we faced, and how we overcame them.

Five Key Strategies for System Transformation

Transforming such a complex system required a deliberate, step-by-step approach. Here are five strategies we employed to navigate this challenging process.

Abstraction as a Foundation for Transformation

One of the first things we tackled was decoupling core systems from their consumers. This involved creating smaller services that acted as intermediaries between the core systems and the end-users.

This approach enabled us to:

  • Remove outdated or irrelevant data (‘trash data’) and supply only what was needed
  • Enable future system migrations without disrupting consumers like websites or third-party integrations.

By abstracting away the core systems, we created flexibility and reduced the risk of breaking downstream dependencies during updates or migrations.

Defining and Standardizing Service Offerings

To bring order to chaos, we needed to understand what services we were offering and who was using them. This required:

  • Conducting a full inventory of platforms and tools, mapping out who used what.
  • Identifying essential services and bundling them into packages (e.g., a basic package for email, CRM, and financial systems).

This process uncovered underutilized services, such as a subscription module in use by just two federations. Phasing out such services reduced complexity and saved resources.

Establishing a Long-Term Vision with Flexibility for the Short Term

We created a five-year roadmap for the system, defining:

  • Core architectural goals and service boundaries.
  • The decision to move to the cloud or stay on-premises.

However, long-term planning had to balance short-term needs. For instance:

  • Requests for minor data modifications to the CRM system were rerouted to a content management system if the data was temporary.
  • More permanent changes were implemented through new intermediary services rather than modifying the core system.

This approach ensured that immediate needs were met without derailing the transformation.

Taking a “Piece-by-Piece” Approach

Transforming the entire system at once would have been overwhelming. Instead, we tackled it incrementally:

  • We started with foundational systems like financial platforms, ensuring continuity for critical revenue-generating processes.
  • From there, we built smaller services that could integrate seamlessly into the evolving platform.

By focusing on incremental progress, we were able to test and refine our approach while minimizing disruption.

Decommissioning Legacy Systems Along the Way

One of the most liberating steps was shutting down outdated systems. Often, these systems:

  • Had unclear ownership or purpose.
  • Consumed resources without delivering value.

For example, we decommissioned an Azure SQL database costing 50,000 Norwegian crowns annually. Despite notifications, no one complained when it was shut down—clear evidence of its obsolescence.

This process not only reduced costs but also streamlined the platform, making it easier to manage and maintain.

Challenges in System Transformation

While these strategies laid the groundwork, the transformation wasn’t without its challenges. Here are the key hurdles we faced.

The Financial Burden

System transformations come with significant costs. A major challenge was determining:

Who should pay? Should it fall on the central federation, the connected federations, or both?

What’s the ROI? Leadership needed a clear business case to justify the expense.

To address this:

• We estimated the cost and time needed for new systems.

• We tracked the resources spent maintaining the old systems. For example, fixing issues with our identity and access management system took nearly a full-time employee weekly. Presenting these numbers made the financial benefits of transformation clear.

Slowing Down Regular Operations

Transformation required shifting resources away from everyday operations. Users, accustomed to rapid bug fixes and new features, had to adapt to slower progress.

To mitigate this, we:

• Prioritized transparent communication with leadership.

• Aligned expectations, ensuring users understood the reasons behind delays.

To Fix or Not to Fix – Legacy Bugs

Deciding whether to fix bugs in the legacy system or work around them was a constant balancing act. These decisions were based on the effort required, the impact on users, and the overall timeline for transformation.

For example:

A bug in the ERP system prevented some users from assigning projects to invoices. Fixing it would have taken significant time, delaying the transformation. Instead, the finance team implemented a manual workaround for the few affected cases, allowing us to focus on building the replacement system.

This approach required close collaboration with stakeholders to weigh the trade-offs and prioritize long-term gains.

Most challenges weren’t technical—they were organizational. Gaining buy-in, managing expectations, and balancing competing priorities required constant collaboration between technical teams and leadership.

Engaging leadership early and delivering data-driven insights helped us maintain alignment and momentum.

From Chaos to Control

Looking back, the transformation was a massive undertaking, but it was worth every effort. Today, the organization operates on a modern platform with:

• A clearly defined architecture.

• Scalable, event-driven services.

• Robust control over data and service usage.

The positive impact is evident in the day-to-day operations. Systems are reliable, integrations work seamlessly, and the organization is poised for future growth.

Transforming a chaotic system is never easy. It’s a journey filled with hard decisions, technical hurdles, and organizational challenges. But with a clear strategy, incremental progress, and the courage to shut down what no longer works, you can turn chaos into control.

I held a presentation on this topic at Trondheim Developer Conference in October 2024.

From the stage at TDC24

To get more details regarding this topic, you can download the presentation here:

You can also watch the presentation here:

If you’re embarking on a similar journey, I hope these strategies and lessons inspire you to take the first step toward transformation.