WordPress engineering and migration
Two situations bring people to this page. One is a WordPress estate that has become slow, fragile or risky to change. The other is a product that outgrew the CMS it was built in. We take both, and we will tell you which one you have.
01Capabilities
The work an ageing WordPress estate actually needs
WordPress is very good at one job, publishing and managing content, and it usually ends up doing four or five jobs beyond that. These are the shapes of work we take on, including the one that ends with moving off it.
- Editorial
Content platforms editors can actually run
Custom blocks, editorial workflow, roles and multisite structure, built so the people publishing every day do not need a developer. This is the case where WordPress genuinely beats anything we would write from scratch, and it sits inside our web development work.
- Integration
Custom plugins and the systems either side
The connective work between WordPress and a CRM, an ERP, a payment provider or an identity system, done as versioned plugins rather than edits to a theme. The engineering here is retries, idempotency and what happens when the other side is down. See platforms development and integration.
- Rescue
Performance, security and the fear of deploying
Plugin sprawl, a page builder generating markup nobody can style, an unpatched core and a database full of orphaned options. Most of what gets described as a WordPress problem is an operational problem, and it responds to maintenance and support rather than to a redesign.
- Migration
Moving a product off the CMS
When the CMS has become the constraint, we move the content model, preserve the URL surface with a real redirect map, and rebuild the parts that were never a content problem in the first place. That is legacy modernization work, and it is a job we take on in full.
02Case studies
Published builds either side of the CMS boundary
Two published builds, one in sport and one a modernization of a training-software product.
See all case studies
SportSports app development for Triathlon associationunicrew engineers modernized the sports website and built a mobile app for better membership management and race planning.- EducationModernizing the UI of a training-software product (CaT Concepts)One unicrew engineer mapped the existing implementations in CaT Concepts' application onto a set of new UI components that already existed.
03Fit
A content site, or an application that happens to have content?
The useful question is not whether WordPress is good. It is whether you have a content site, or an application that happens to have content in it. WordPress is excellent at the first and becomes a liability at the second. Each row below names the build or the platform that fits, from WordPress to Magento or Moodle, with the reasoning in each.
| Your situation | What we recommend |
|---|---|
| A content site: editors publishing every week, and the pages are the product | Use WordPressNothing we would build from scratch beats it on editorial ergonomics. Rebuilding that layer is spending money to end up with something worse. |
| An application that happens to have content: user state, permissions, workflow, calculations | Application firstBuild the application, and leave the CMS holding the content beside it. WordPress used as an application framework becomes a database with strong opinions. |
| A store with a large catalogue or per-customer contract pricing | Different pageNot a plugin. That decision sits on Magento or Shopify, and it turns on catalogue complexity rather than on what your marketing site already runs. |
| The site is slow and carries thirty plugins, but the content model still fits | Clean up firstCut the plugin surface, fix caching, and get a real deploy path first. Migration is the expensive way to buy what a cleanup delivers. |
| Courses, cohorts and certification tracking, currently on a plugin | Different pageLook at Moodle or a bespoke build. Learning platforms outgrow WordPress plugins earlier than anything else we meet. |
| You want a decoupled front end on Next.js | For product front endsWorth it when the front end has real product requirements. Not worth it as a page-speed wish, because you then operate two systems and a preview problem. |
Scope
What we own on WordPress work is the judgement about which situation you are actually in, and everything downstream of it. That means the upgrade path, the plugins you become dependent on, and whether your team can still change the site after we stop. unicrew has been building and rescuing content platforms since 2012, with 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. Where extending what you have is the cheaper answer, that is the route we recommend.
WordPress is the right fit for a content site. For an application with some content in it, we build the application first and keep the content in WordPress beside it. Either way, the logic lives in versioned code your team can review and test.
Yaroslav HavrylivSenior Engineering Manager, unicrew04Delivery
Where we start when somebody else built it
Inherited WordPress is the normal situation rather than the exception. This is the order we work in, and step two is the one people want to skip.
- Inventory the plugins and the custom codeWhat is running, what is abandoned upstream, and where business logic is hiding in a theme's functions file. An unmaintained plugin with database write access is a risk you are carrying whether or not anyone has written it down.
- Get it into version control and a real deploy pathEditing on production is the root cause of most of what looks like a WordPress problem. Until there is a repository, a staging environment and a way to roll back, every improvement we make is one file transfer away from being undone.
- Close the security positionCore, plugin and PHP versions, users holding more rights than their job needs, and anything unmaintained that touches the database. This is not optional work you schedule for later; it is the floor everything else stands on.
- Then decide, extend or move, in writingYou get a written recommendation covering the content model implications, the URL and redirect consequences, and the smallest change that solves the problem. Extending WordPress and moving off it are costed side by side, so the choice rests on the numbers.
05Stack
The four decisions sitting next to this one
What a WordPress build is made of and what it is most often traded for, each with its own page.
06Questions
The questions that decide fix or move
Answered the way we would answer them live, including the ones where a cleanup beats a migration.
Yes, and on an existing estate it often makes sense, because your people hold the context. Every developer comes with ownership of the result: an architect outside the delivery team reviews the design before plugin work starts, and the code goes through the same QA and test automation practice as our own projects. Team extension is managed teams; handing over the outcome is web development.
It depends on whether the CMS is the constraint or the operations are. If the content model still fits and the pain is speed, plugin conflicts and fear of deploying, that is operational, and a migration will faithfully reproduce it somewhere new. If you are writing application logic into hooks, the CMS is the constraint and moving is the right answer. We put that judgement in writing first.
Yes, and it is a large share of the WordPress work we do. We start from what actually runs rather than from the handover document: plugin inventory, custom code, the database, the scheduled jobs, and whatever integration nobody mentioned. The first stretch goes into version control, staging and a rollback path, so feature work lands on a foundation you can trust.
A normal theme unless you have a specific reason. Going headless with Next.js buys a front end you can build like an application, and it costs you preview, the editor's confidence about what a change will look like, and a second system to operate. That trade is worth making for real product requirements. It is not worth making to fix page speed.
A scoping call with an engineer rather than a salesperson. For an existing site we ask for read access to the repository, or failing that the file tree and the plugin list, because an hour in the code beats three spent describing it. What comes back is a written read on what we would do first and what we would keep. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based and quoted per project, and we offer it once the first read is done, because a fixed number on an estate nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Is the CMS the constraint, or is it the way you run it?
Send us the site and the plugin list. You will get an engineer's read on where the constraint really sits, and whether a cleanup or a migration fixes it.