What a Complex Publishing Migration Says About the Website Partner You Need

There is a point in the life of a website when “just add another plugin” stops being a solution. The site may still be online and look respectable, but inside the business every change is taking more care than it should. Publishing feels fragile. Performance fixes collide with old dependencies. New features have to negotiate with years of previous decisions. That is usually when a website stops being only a marketing asset and becomes operational infrastructure.

A redesign changes what customers see. A modernisation changes what the business can do next.

One of Inzint's recent engineering projects made that distinction unusually clear. La Cuisine de Bernard is a long-running culinary platform with more than 1,300 original recipes published since 2010, many documented with step-by-step photography. The archive was not material to throw away while making a new homepage. It was part of the value of the business.

The real question was therefore not “Can we make this website look newer?” It was “Can we change the platform while protecting everything the website has already earned?” For founders, owners, and marketing teams in Oman considering a redevelopment, that is the more useful question.

A website can be working and still be holding the business back

There is nothing inherently wrong with WordPress. For the right scope, it remains a useful platform. The problem is assuming that the system a business started with must remain the system it grows into.

Over time, a website can become dependent on plugins, templates, workarounds, and historical conventions that were individually sensible decisions. Years later, those decisions begin to interact. A simple publishing change touches three tools. A speed improvement breaks an old integration. Nobody wants to remove a particular plugin because nobody is certain what else depends on it.

This is platform debt. Unlike a dated colour palette, it does not disappear when the homepage receives a visual refresh.

Visual redesign	Platform modernisation
Changes layout, typography, and presentation	Changes how content is structured, managed, and delivered
Can leave old dependencies untouched	Examines dependencies, data, integrations, and ownership
Answers “How should the site look?”	Answers “What must the business be able to do next?”
May be the right answer for a healthy foundation	Becomes necessary when the foundation limits growth

Content is a business asset, not disposable migration data

For La Cuisine de Bernard, the historical WordPress archive was roughly 2GB and had accumulated different content structures over years of publishing. Some images existed inside rich text. Recipe steps did not always use the same media pattern. Older and newer entries reflected different editorial assumptions.

That made the migration a data-engineering problem, not a one-click CMS transfer. The team first had to understand what each variation meant, then design a destination model that preserved the editorial reality without copying every accidental constraint of the old platform.

The new delivery system used Next.js, Payload CMS, and MongoDB, with a DeepL-powered translation workflow. The stack matters, but the deeper lesson is that the content model was built around the content that actually existed. The recipes, photography, expertise, and voice remained the client's. Inzint's job was to make that asset more durable.

Messy data is where website partners reveal themselves

A migration plan often looks beautifully simple in a proposal: export, import, test, launch. Real websites are less polite.

Years of publishing create exceptions. A field changes. An editor discovers a useful workaround. A plugin stores something differently. Images appear in places the new content model never expected. The awkward records are not noise to ignore; they are the cases that prove whether the migration model is safe.

When choosing a company for a serious website redevelopment, ask less about whether it “knows WordPress” or “knows Next.js”. Ask what it will do when your data does not look the way its migration script expects.

Multilingual publishing should be architecture, not decoration

Oman businesses have an additional reason to think carefully about content structure. English and Arabic are rarely just a language switch in the header. Once a website becomes a meaningful acquisition or service channel, multilingual content affects fields, URLs, metadata, editorial workflows, search visibility, review responsibilities, and future updates.

The La Cuisine de Bernard project was not an Arabic-language case study. Its translation workflow demonstrates the broader principle: translation should have a defined place in the content platform rather than being bolted onto the front end. Payload's localization model, for example, manages multilingual content at field level.

For an Oman website, the exact technology may differ. The architectural requirement does not. Arabic and English content should be manageable assets with clear ownership, parity checks, publishing states, and fallbacks—not duplicated pages that somebody has to remember to keep synchronized manually.

“AI-readable” should mean clear, structured, and evidenced

AI readability does not mean adding paragraphs of keywords for ChatGPT. It means giving both people and machines a clear representation of the business or its content: understandable headings, descriptive text, explicit entities, sensible internal links, page-specific metadata, valid structured data, crawlable pages, and evidence for important claims.

That matches Google's guidance for generative AI features in Search: foundational SEO, a clear technical structure, and unique, valuable content still matter. Google explicitly advises publishers to focus on useful, non-commodity material rather than chasing supposed AEO or GEO hacks.

ChatGPT search has a similarly practical requirement. OpenAI's guidance for publishers explains that public sites should not block OAI-SearchBot if they want their content to be eligible for discovery, summaries, and citations. That creates eligibility, not a ranking guarantee.

So the useful version of AI readability is not a trick. It is the removal of needless ambiguity. Humans generally appreciate that too.

Continuity is a feature

The migration ran from 25 April to 18 August 2026 and the new platform went live with near-zero downtime. That may sound less dramatic than announcing a new framework. Operationally, it was one of the most important outcomes.

A growing website already has readers, customers, organic-search history, bookmarks, incoming links, and people who expect it to work. A launch that destroys that continuity in order to celebrate a new design has misunderstood the job.

Google's site-move guidance recommends preparing and testing the replacement, mapping old URLs to appropriate new destinations, using permanent redirects, and monitoring the move. Continuity matters to search systems as much as it does to users.

The feedback matters because of what it praised

The project ended with a 5.0 client rating. The number is welcome, but the sentence behind it says more: the client described Inzint as solution oriented, clear in communication, accountable for outcomes, and attentive to detail.

Those are precisely the qualities that matter when a migration stops behaving like the neat spreadsheet everyone expected. Difficult platform work requires someone to keep asking what an exception means, what could be lost, what needs to be tested, and what the client must be able to do after launch.

Framework knowledge matters. Being able to find the right solution when the real data refuses to resemble the specification matters more.

Five signals your Oman website needs more than a redesign

1. Publishing takes too much effort. Routine updates require a developer, several tools, or risky workarounds.
2. Plugins have become dependencies nobody understands. Removing or updating one feels dangerous because its relationships are undocumented.
3. Performance improvements never last. Each fix treats a symptom while the underlying architecture keeps adding weight.
4. Arabic and English content drift apart. Translation, metadata, URLs, and updates have no shared workflow or accountable owner.
5. Every new feature requires old compromises. The roadmap is being shaped by the limitations of the platform rather than the needs of the business.

Any one of these can be repairable. Several together are a reason to assess the platform before commissioning another visual redesign.

Change the engine without losing what the website has earned

A proper modernisation begins one layer deeper than design. It starts by understanding the information the business owns, deciding how that information should be structured, choosing an architecture appropriate to the next phase, and planning the transition without casually discarding what already works.

That is the capability the La Cuisine de Bernard project tested: not the ability to install a new theme, but the ability to change the engine while protecting the value accumulated around it.

If your website may have outgrown the system underneath it, start with evidence. The Inzint Website CT Scan reviews structure, performance, SEO, content clarity, AI readability, and lead paths before you decide whether to repair, redesign, or rebuild.