Rescuing a misconfigured Magnolia instance: clean install, WordPress migration and multibrand architecture

An inherited Magnolia instance is a common situation: the product works, somebody configured it at some point, and nobody knows how. GDA, a Mexican laboratory group, started there.

The problem with a misconfigured platform is not that it fails. It is that every change costs more than it should and nobody can tell you how much in advance.

The instance carried a single brand, built on decisions nobody had written down.

• No documentation: there was no record of how the instance was built or why the existing decisions had been made.
• Access problems: entry to the environments was compromised, which blocked any serious diagnosis before it started.
• Content outside the platform: much of the material lived in WordPress, on a different stack from the one the group wanted to keep.

What was at stake was not the old instance but the next decision: that foundation could not carry the multibrand architecture the group needed.

We audited the instance, concluded that reinstalling cost less than fixing it, and left the configuration documented and ready to scale to several brands.

This is diagnostic work before it is development work: the hard part was not running the reinstall but determining that it was the right call.

Audit and decision

• Assessment of the real state of the instance, its configuration and the available access.
• Comparison between fixing the existing configuration and reinstalling from scratch, with the cost of each path on the table.
• Decision to reinstall, made on the assessment rather than on a technical preference.

Clean install, configured correctly

• Clean Magnolia install with the configuration the multibrand architecture required from day one.
• Access problems resolved and environments put in order.
• Documented configuration, so the next person to touch it does not have to reverse engineer it.

WordPress migration and guidance

• Migration of the content that lived in WordPress into the new platform's content model.
• Guidance for the client's team on how to implement each adjustment, rather than handing over only the outcome.

Architecture and technology

• Magnolia CMS reinstalled and configured for multisite operation.
• Decoupled headless front end consuming content over API.
• Content migration from WordPress.

Learn more about Magnolia support and maintenance.

Learn more about software development.

The instance stopped being an obstacle and became the foundation the group used to launch eight brand sites.

Starting point

• Inherited instance with no documentation and compromised access.
• A single brand configured, and badly configured.
• Content split between Magnolia and WordPress.

Results

• Clean install, with the configuration documented and verified.
• Multibrand architecture in operation, with eight sites live on the new foundation.
• WordPress content migrated into the final content model.

Strategic impact

• The group stopped carrying configuration decisions nobody could explain.
• It settles the underlying objection: a misconfigured instance gets rescued, not abandoned.