HKHenrik Kiepe – Operations

More Than a New Theme: The Controlled Modernization of Relevante Ökonomik

ArticleCreated 2026-08-26Updated 2026-08-31published

Linux OperationsAnsibleOpenTofu / TerraformAutomationMonitoring / ObservabilitySecurity-conscious Infrastructure

How a website relaunch separated migration, infrastructure renewal, staging acceptance and restore planning while leaving the archive migration for a later step.

A website relaunch should not begin with colors, fonts or a new home page. When I started volunteering technical support for Heiner Flassbeck and Relevante Ökonomik, the technical foundation first had to be understood and renewed.

In an earlier article, I explained why I became involved in this project. What began as a set of initial improvements became a broader infrastructure and relaunch project. The new site is now close to release. The production change is scheduled for August 31, with the public release planned for September 1.

The design is the part visitors will see. The work underneath determines whether the site can be operated, changed and recovered with confidence.

This article deliberately describes the architecture and operational principles without exposing internal addresses, access paths, accounts, secrets, database names, or specific recovery locations. Those details do not belong in a public article.

WordPress was not the real problem

The relaunch could have been used as an opportunity to rebuild everything: a new CMS, a new platform, and perhaps containers, Kubernetes, or another modern stack. That might have been technically interesting, but it would not necessarily have been the right decision. Relevante Ökonomik has an extensive archive of economic-policy articles with established URLs, incoming links, and search history; many of these articles have already been publicly available for years. In that situation, newer technology is not automatically better technology.

WordPress therefore remained in place. What changed was the way it is operated. The guiding question was not “How can we use as many modern technologies as possible?” but “How can we create a system that is understandable, reproducible, maintainable, and recoverable when something goes wrong?”

The result is a deliberately straightforward architecture:

OpenTofu ──► Cloud resources and DNS
                   │
Ansible ─────► Linux system
                   │
                   ├── nginx and TLS
                   ├── PHP
                   ├── Database
                   └── WordPress
                         │
Internet ───────────────►│
                         ├── Site plugin
                         │     └── Content model and workflows
                         │
                         └── Theme
                               └── Presentation and home page

In addition:

Staging ─────► Acceptance before production
Backups ─────► Defined recovery point
Monitoring ──► Technical health
SEO data ────► Search visibility over time

The production runtime is therefore remarkably unspectacular, and that is intentional. Complexity does not disappear, but you can decide where it should live. In this project, as little of it as possible resides in the running production system. Instead, it is concentrated in automation, version control, verification and defined recovery procedures.

Infrastructure as code is documentation first

The core cloud and DNS resources are described with OpenTofu, while Ansible configures the Linux system and its services. This turns:

I think these are roughly the commands I ran back then.

into:

This is what the system should look like.

Ansible configures the web server, PHP, the database, TLS and WordPress, among other components. When a configuration changes later, the repository shows what changed and why. Infrastructure as code provides both automation and executable documentation. For a system intended to operate for several years, that record may be more valuable than the time saved during the first deployment.

The article Modeling an Existing nginx Site Safely with Ansible describes how an existing configuration can be brought into this model without introducing unnoticed drift.

Secrets follow the same principle of separation. Passwords and other confidential data do not belong in the Git repository. They are only provided where they are actually needed.

Do not change several risks at once

One of the most important decisions in this project was not technical at all. It was about sequencing. A relaunch makes it tempting to change many things at the same time:

If something fails after that kind of big-bang deployment, it becomes difficult to identify which change caused the problem. I wanted to avoid exactly that situation. We therefore began by documenting the existing environment and performing a test migration of the website. The production migration, including the domain and DNS, came next. Only after that foundation was working did we modernize the operating system and WordPress. The editorial and visual relaunch then began in a separate staging environment.

This sequence is less spectacular, but far more manageable when something goes wrong. Every step has a defined starting point and a verifiable result.

Staging is not a demo website

The staging environment has its own content and database and is separated from public production. Search engines should not index it, and outgoing email and unnecessary external integrations are disabled. This makes it possible to use the website realistically without notifying subscribers or triggering other production side effects.

Staging is the acceptance environment, not merely a preview. Heiner could use the new home page, content formats and editorial workflows in the system that will later go live, rather than review screenshots or design mockups. This produced several smaller corrections. What appears logical during development is not necessarily logical to the person who will use the system every day.

The current version has been accepted on that basis. This creates a clear boundary for the production change. The release candidate has already been tested in editorial use.

The theme must not own the content model

In WordPress, a surprising amount of logic often ends up in the theme. That works until the theme is eventually replaced. Relevante Ökonomik therefore separates presentation from editorial logic. The theme controls what visitors see, while a purpose-built site plugin defines what a piece of content is. The plugin contains content types, categories, editorial selection fields, home-page rules, sensible defaults, and parts of the workflow.

New content has clearly defined formats:

This changes the editorial workflow. Someone creating an article should not have to determine which combination of WordPress fields is required for it to appear in the right place. A guest contribution, for example, can belong to a primary subject category such as "Current Analysis" while also being marked as a guest contribution. The content model reflects the editorial structure rather than forcing editorial decisions into theme-specific fields.

Less backend can be more

The same principle applies to permissions. A common content-management mistake is to give editors access to almost everything and hope they ignore the technical areas. Heiner needs articles, media, categories, and tags in order to publish. He does not need plugin management, theme configuration, user administration, or technical system settings.

The customized editorial role therefore hides these areas. This improves security, but it also improves the interface. A good administration interface does not show users everything the system can do. It shows them the decisions they actually need to make.

The new home page is an editorial system

The relaunch is most visible on the home page. Until now, it has been dominated by a chronological list of recent articles. The new version reflects more closely how Relevante Ökonomik works editorially. Its sections include:

This structure raises a technical question. What happens if an article is the latest publication, selected as "Currently Important" and assigned to a featured category? Without additional rules, it could appear three times. The home page therefore applies priorities and deduplication. Once an article has been used prominently, later sections skip it.

Very long headlines are handled as well. Instead of truncating them or allowing one title to dictate the layout, their presentation adapts to the available space. The home page must work with real content rather than the small set of headlines used during development. Ideally, visitors never notice these technical rules at all. That is precisely when they are doing their job.

What happens to the existing archive?

The new content structure can also be applied to historical articles. On staging, I have already examined how older articles could be classified automatically and how problematic teaser text could be improved. A larger bulk migration would therefore be technically possible, but it is deliberately not part of the relaunch.

The first production change will include only the functions and content that have already been reviewed. Classifying the historical archive will follow later as a separate work package. Just because a script can automate several hundred editorial decisions does not mean those decisions should be included in the same release.

Being able to automate changes and being wise to release them together are two different things.

A backup still needs a restore path

Before major changes, a current backup is created. That sounds obvious, but it does not answer the decisive question: Can that backup actually be turned back into a working system? A directory full of backup files is not enough. A documented restore procedure must also exist so that files, the database, and the required configuration can be returned to a consistent state.

Immediately before the production change, we will create a defined recovery point. If the release causes an unexpected side effect despite all prior testing, a known state will be available to return to. Rollback should not be an idea invented during an outage; it should exist before deployment begins.

Observability begins after deployment

The work does not end with the release. As part of monitoring and observability, metrics and logs are evaluated centrally. They answer the technical question: Is the platform working?

For a public website, however, that is not enough. Data from Google Search Console is also collected automatically and retained for long-term analysis. This adds a second perspective: Can people still find the content?

The distinction is particularly important after a relaunch. A website can return HTTP 200, have low response times, and appear completely healthy in monitoring while important content disappears from Google Search. Technical availability and search visibility are not the same thing, so both must be observed.

What I am taking away from the project

Relevante Ökonomik is not a vast distributed software system. It shows why established operations principles matter long before hundreds of servers are involved:

The common thread is traceability. Infrastructure as code is not merely a deployment method. It records operational decisions in a form that can be reviewed and applied again.

Shortly before the release

At the time of writing, the existing website continues to operate unchanged. The new version is technically prepared and has been accepted editorially. The production change is scheduled for the late afternoon of August 31, 2026. If the final checks succeed, the new Relevante Ökonomik site should become publicly visible on September 1.

After release, we will observe the platform under real operating conditions and classify the historical archive step by step. Further changes will follow from actual editorial use rather than assumptions made before launch.

The most significant change may not be the new design at all. It is the fact that the next modification no longer has to begin with the question “What will probably happen if we change this?” Instead, we can ask: “How will we test it, how will we release it, and how will we return to a known state if our assumption is wrong?”

That, to me, is reliable operations.