From Problem Child to Cloud Guide: How the Wegwijzer Transformed Wigo4it

What do you do when one of your members is ready to leave, and the market says others can do your job better and cheaper? At Wigo4it - the G4’s public IT partner in social welfare - that question sparked a radical reset. Not just of systems, but of mindset. The Wegwijzer became the symbol of that shift: from control to trust, from complexity to clarity. A digital transformation that turned out to be, above all, a cultural one.

Introduction

Since 2007, Wigo4it has been the technological backbone behind social welfare payments for the four largest cities in the Netherlands: Amsterdam, Rotterdam, Utrecht, and The Hague. Each month, over 110,000 households rely on us to receive their benefits accurately and on time. This includes standard social assistance as well as more recent programs like refugee support for Ukrainians, energy subsidies, and COVID relief. All of it is handled by our application, Socrates, which processes over 4,400 legal rules. That reliability is the core of what we do and we’ve never missed a payment.

In 2019, however, we were forced to take a hard look at ourselves. A market analysis by Deloitte concluded that the private sector could offer similar services for less money. One of our members even considered leaving the cooperative. That moment sparked a fundamental transformation, not just in our technology, but in our culture and financial model as well.
Together with Xpirit (now Xebia) and Microsoft, we developed a roadmap that changed everything. We moved from service to self-service, from private datacenters to the public cloud, from custom-built systems to SaaS, and from traditional project management to full DevOps. All of this was done while cutting our budget in half—from €36 million to €19 million within four years.

One of the most important outcomes of this transition is the Wegwijzer. In the past, municipalities had to go through long and frustrating processes to request new environments, for testing or user education for example. It could take up to three months. Therefore, once environments were provisioned, they were never removed or deactivated, resulting in them running 24/7, 365 days a year, while being hardly used. Today, thanks to a self-service portal, they have full control.

The "Wegwijzer" (Signpost) became the symbol of that change: a self-service portal that lets municipalities deploy, manage, and scale their own Socrates environments in the cloud. It offers instant access to test, training, and production setups, all within clear cost and sustainability limits. What began as a cost-saving tool became proof that public IT can be both innovative and human-centered.

How it works

Socrates itself is a complex system with many moving parts in terms of software and Azure infrastructure. Different teams (value streams) within Wigo4it contribute their individual components to the product, but it all has to work together when deployed. With our shift towards DevOps, "automate everything" became an important mantra. No more static installation manuals or error prone manual installation steps, everything had to be predictable, repeatable and thus completely scripted with infrastructure-as-code. Terraform was the tool of choice across the organization.

Deploying an entire Socrates environment involves pulling the Terraform modules from all individual components together, and then orchestrating them in one deployment run with a number of input parameters describing the environment. Even after automating everything, this can take up to several minutes. Everything from deploying backend pods in Kubernetes, database schema upgrades, creation and deployment of Azure WebApps to creation of app registrations in EntraID, all of it is part of the deployment process.

But even just several minutes of waiting time is substantially better than hours to days of work and manual labour.

Architecture

In order to kick off this complex deployment process, we needed a user friendly application, one that can also be used by non-techy functional managers at the municipalities. This became the Wegwijzer.

Since we were preaching reducing the footprint of Socrates in the cloud, we also needed Wegwijzer to have a small footprint. We opted for a cost optimized architecture:

The front end consists of two separate applications: a multi-tenant admin application for Wigo4it that lets us manage all environments for all municipalities and a simplified single tenant application for the municipalities where they can only see and manage their own environments.

Production environments are still managed by Wigo4it using the Wegwijzer Admin app. Wigo4it developers also use this application to manage their internal development environments as well as environments for automated end-to-end tests that run as part of the Socrates CI/CD cycle.

The Azure Functions backend serves data to the front end, such as which environments exist, their definition and their credit spend. End users can also have an overview of the credit spending over time during the year.

After defining (or updating) an environment definition, the backend application triggers a durable functions orchestration which handles the dispatching of the deployment, waiting for its completion and processing the outcome of the deployment. Some deployments may still fail due to intermittent errors in Azure or due to bugs in the Terraform code of one of the teams.

The actual deployment process - running the Terraform code - is done through an Azure DevOps pipeline, which are very suitable for this type of long running deployment processes.

The Wegwijzer orchestration invokes the pipeline through the Azure DevOps REST API, and goes to sleep until the pipeline posts a message to a storage queue when it's done. This wakes up the orchestration which processes the result (success or fail) and updates the environment's status in the database.

Once an environment is successfully deployed, it starts incurring costs, which is something we need our end users to be aware of.

Cost awareness

Wigo4it is charged for the Azure consumption of all the components we deploy in the cloud. To make it manageable for the municipalities, we decided to abstract these detailed and mostly technical costs into a "credit system". Each municipality receives 50,000 credits per year, valued at €3 each, to deploy environments as needed. One credit covers one hour of runtime. If they want production data or a service-level agreement, that also costs a credit. A full production environment costs a maximum of €9 per hour. More importantly, municipalities decide when to deploy, scale, or shut down an environment.

Where most market vendors offer four environments (test, acceptance, production, and maybe development), we used to offer sixteen by default. Municipalities kept them running because requesting new ones took too long and too much effort. But now that they can create and delete environments in minutes and have control over the associated costs, they’re much more selective. For the past two years, every municipality has stayed well within their credit budgets. They never needed sixteen environments. They just needed a better way to work.

Credit calculation

Credit calculation is done by looking at the history of each environment. Every change, including deleting an environment, is tracked in a history table. We can then easily construct a historical view of the environment and how much it cost at any given time, even down to a second in accuracy. For simplicity, we round off to hours though as we don't work with fractional credits.

Within the lifespan of an environment, we can calculate how many hours it was turned on, how many business hours it received support (that is excluding weekends and public holidays) and how many hours it had non-anonymized production data - requiring heavier security measures.

For example, if an environment had support for a while, and the municipality turned this off at some point in time, we can see the spend go down from 2 credits to 1 credit per hour at that very moment. By doing this for all environments, we can draw graphs like this one:

This provides immediate and always up-to-date insights in credit spend, including a forecast until the end of the year, based on the currently deployed environments. (This municipality should really turn off one or two environments to avoid using up all credits by November 11).

Green IT

Apart from the financial benefit of lower cost, reduction of the number of environments and a shorter lifespan, the environmental footprint also becomes smaller. Wigo4it has a strong focus on sustainability and wants to encourage this awareness with their end users as well.

On each environment tile in the user interface, we placed an indicator - a small green leaf 🍃 - which shows the impact of the environment expressed in kgCO2e emission since the environment started running. We calculated this using Azure's Carbon Optimization REST API. Danny van der Kraan described this API in his article titled "Sustainable Software Engineering Through the Lens of Environmental, Part 2: Measuring" in XPRT. Magazine #16.

The challenge here is that each environment has both dedicated Azure resources which can be easily attributed to this one environment, as well as shared resources such as a Kubernetes cluster and an Oracle database cluster. It makes it more difficult to assign an exact number for each environment because the Carbon Emission API does not give us that detail. For that reason, the carbon footprint is partly a "guestimate" for now, but we feel it's an important piece of information to show to our users.

If you want to learn more about this, check out Wigo4it's Sustainability Radar at https://duurzaamheidsradar.wigo4it.nl.

Conclusion

It started as a cost-saving measure. We estimated it could generate an extra €1 to €2 million, but it has become a symbol of trust, autonomy, and cloud maturity. It’s not just a change we made inside our own organization. It has also started to influence the culture of our member cities. And in many ways, the cultural shift has been just as important as the technical one.

The Wegwijzer is more than a portal. It’s proof that governments can work in the cloud with agility, scalability, and a strong focus on user needs—if they’re willing to change both culture and technology together. Public money should never be treated as a given. It deserves to be challenged, justified, and used wisely.