Most content platforms are not chosen twice. The decision is made once, under pressure, and then everything the business publishes runs through it for years. We work on the systems that carry that load — including the migrations that move content from one to another without losing it.
A content platform tends to be selected before anyone knows what the editorial workflow will actually become. Three years later the same platform is carrying content volumes, integrations and community behaviour nobody planned for. The work that follows is not a rebuild; it is engineering against a system that already exists, already holds the data, and cannot be taken offline to be improved.
Each links to the full capability page — the problem it addresses, how we work, and the evidence behind it.
A community platform is judged in public and cannot be taken offline to be improved. We work on forum platforms that are already carrying an audience, where the constraint is not building the feature but shipping it without an upgrade becoming a project of its own.
The difference between a modification and an add-on is not how it behaves on the day it is installed. It is what happens eighteen months later when the platform moves a version and somebody has to work out what your functionality depended on.
A forum's load is set by its members' habits, not by a marketing calendar. Capacity is decided by the peak hour of a community's day, and the peaks are predictable right up until they are not. We operate the layer that has to hold under both.
A forum's performance problem is almost never where the front page suggests. Thread rendering at depth, unread-state queries and search over a long history are the expensive paths, and they are invisible until a community is large enough for them to matter.
A community platform needs someone who applies the update before it becomes urgent, notices when an extension stops being maintained, and can say what changed last month. That is a cadence rather than a project, and it is what keeps an upgrade from becoming archaeology.
Whether a forum can be migrated is a question about its source schema, not its size. Some sources are covered by the target platform's own importer and some are not, and that single fact decides whether this is a bounded project or a development one.
A new installation is a build. An upgrade that has been deferred for several versions is a project, and the two are different enough that they belong on the same page only to make the distinction clear.
Sometimes the source is a bespoke forum, an abandoned platform, or a heavily modified installation that no converter was written for. That is a development project rather than a configuration one, and the work is in understanding what the source actually contains before deciding how it maps.
A forum migration is a data reconciliation problem. The software is the easy part. What decides the outcome is whether the source schema maps onto the target cleanly, what happens to the parts that do not, and whether the community's search visibility survives the move.
Invision Community has been renamed, re-versioned and restructured over a long life, which means two installations describing themselves identically can behave completely differently under migration. The version position is established before anything else is planned.
A forum is one of the worst things to migrate from a search perspective. Its value is decades of deep, internally-linked discussion, and every one of those addresses is about to change. The move is recoverable; the redirect map is what recovers it.
At a certain size a forum migration stops being a conversion problem and becomes a logistics one. The questions are how long the data takes to move, how much of it changes while it is moving, and how to prove nothing was lost when the counting itself takes hours.
WordPress is capable of running a serious website. Whether a given WordPress site is serious depends almost entirely on the discipline applied to what goes into it — which plugins, which customisations, and what happens at the boundary between them.
Maintenance is not applying updates. It is deciding when to apply them, testing them somewhere that is not the live site, knowing how to reverse them, and being the party who notices when a backup stops completing.
WordPress slowness almost never has one cause, and most attempts to fix it are a plugin installed on top of the problem. The two questions that matter are where the time actually goes, and how to change things without a feature quietly stopping.
A move between servers keeps the software the same and changes where it runs. This is the other thing: changing what the content lives in. The content model is the real work, and the URLs are what the move puts at risk.
A bespoke plugin is the one part of a WordPress site that nothing else updates. That single fact decides how it should be built, documented and tested — and it is what most plugin projects underestimate.
Hardening WordPress has an enormous amount of published guidance and very little of it is an engagement. Here is what is actually delivered, what it changes, and where the decisions are yours rather than ours.
Cleaning a WordPress site is the easy half. The half that decides whether it comes back is verification — and on WordPress there is a specific list of places a clean-looking site still hides code.
Multisite is one installation serving many sites, sharing users, plugins and themes. It solves a real problem and it is chosen far more often than it is warranted, and the cost of choosing it wrongly is paid by whoever has to work inside it later.
An integration is not the request that works. It is what happens when the other system is down, slow, or answers with something you did not expect — and that is the part that is usually left unspecified.
A store is a catalogue, a checkout and a set of integrations that all have to keep working under load. That is an engineering problem, and it is where most stores break — not in the theme.
Headless is a trade rather than an upgrade. It moves work from the server to a build pipeline and from the theme to an API, and whether that is a good trade depends on what you are delivering and who has to edit it. The first thing we do is establish which side of that line you are on.
Headless WordPress is usually proposed because the front end needs to be something WordPress cannot be. The editing experience is worth keeping, and the cost of keeping it is a set of problems that only appear once the front end and the CMS are separate.
This is the application rather than the architecture: routing, how each route renders, where its data comes from, and what it does while that data is arriving or failing.
Astro's default is that a page ships as HTML and nothing else. This is the engineering that decision leaves to you: which components are interactive, where their data comes from, and what a crawler actually receives.
Moving to Next.js is a statement about the front end. It says nothing about where the content lives, and that is the decision that decides whether this is a front-end project or a full replatform.
This is not a like-for-like replatform. Next.js is an application builder that can serve documents; Astro is a document builder that can host an application. The shape of the migration follows from how much of your site is which.
A headless CMS stores content as structured data and renders nothing. That changes what a migration has to produce: not pages that look right, but a model everything downstream can be built from.
The CMS is chosen and the frontend is built. What is missing is the contract between them — and the parts of it that nobody specifies, which are preview, invalidation and what happens when one side is unavailable.
A theme is a set of changes to a platform that keeps moving. Styling written where the platform expects it can be upgraded indefinitely; styling written into copies of templates is lost the first time the platform changes one.
A forum's homepage is a list of forums, which is the right page for members and a poor one for everyone else. A portal is the answer to that, and it raises a question the forum did not have: which of the two is the site.
A community holds members, permissions, content and activity, and other systems frequently want some of it. The question is which parts, who owns them, and what happens when the other system is unavailable.
phpBB is one of the sources a forum migration is most likely to go well from, because the structures are close. What decides the outcome is the part the importer does not carry — permissions, attachments, and the details an old board accumulates.
Discourse and XenForo disagree about what a thread is, how identity works and how trust is expressed. None of those has a conversion — they have a decision, and making them is the migration.
There is no importer for a forum somebody built. The work is reading a data model nobody documented, working out what its columns mean, and constructing the verification that a reference implementation would otherwise have given you.
WoltLab is not one source. Its major versions changed the data model substantially and its applications are separate products with their own tables — so the first question is which WoltLab, not whether WoltLab is supported.
Managed is the least specific word in this market. Here is what is actually covered — the distributions, the stacks, and what patching, backup and monitoring each mean in practice.
Database slowness is usually attributed to the database and frequently caused somewhere specific — a missing index, a query shape, a schema that grew past its assumptions. Finding which is the work, and there is no setting that substitutes for it.
A CDN is a cache with a copy of your site in it. Configured well it removes most of the load from the origin; configured carelessly it serves one visitor's page to another, and the failure is invisible until someone reports it.
Work where this cluster was the substance of the engagement.
Since 2019, Soludome has managed infrastructure and platform operations for one of Spain's largest online communities. The work covers server and performance optimisation, CDN architecture, load balancing and site security under sustained traffic.
An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.
Since 2021, Soludome has managed infrastructure, site performance and technical SEO across GuzziTech and RideMalibu as a connected web estate. The engagement includes dedicated infrastructure and continuing operational ownership.
The disciplines support each other. A platform that cannot stay up cannot be crawled reliably, and a search problem frequently turns out to be an infrastructure problem.
Building AI into systems that have to work in production.
Making complex sites crawlable, indexable and citable.
Keeping high-traffic systems fast, available and secure.
Describe what the system is doing. Working out which discipline applies is part of the diagnosis, not something you should have to guess.