Alright, so you’re looking at moving from TYPO3 to WordPress.
Maybe your version just fell off free support and the renewal quote made someone stop and think. Maybe the one person who knew TypoScript has left. Maybe marketing asked for a new kind of page section six weeks ago and it still isn’t live.
Any of those is a fair reason to start reading.
One honest warning before you go further. Moving off TYPO3 takes real engineering work. Your site holds years of custom extensions, a page tree shaped by choices nobody wrote down, and settings that sit in PHP files rather than in the database. You can’t open the database and see how your site works. Someone has to read the code first.
That reading is the piece most vendors leave out of a quote. It’s also the piece that decides whether your timeline holds.
This guide walks through the whole decision, start to finish. It’s built on 300+ enterprise migrations, and it’s straight about the hard parts: where the money really goes, what makes a schedule stretch, and which early calls cost a lot to undo. It also covers the cases where the right answer is to stay on TYPO3.
Here is the roadmap:
- PART 1: Should You Really Migrate? The Decision Framework. Start here
- PART 2: Understanding Your Migration Complexity. Start here
- PART 3: Choosing the Right Migration Partner. Start here
- PART 4: Why You Should Migrate from TYPO3 to WordPress. Start here
- PART 5: How to Migrate from TYPO3 to WordPress. Start here
- Frequently Asked Questions. Start here
If you would rather talk it through than read 9,000 words, you can schedule a free consultation with one of our migration leads.
PART 1: Should You Really Migrate? The Decision Framework
Before scoping anything, work out whether the move is justified. TYPO3 suits a particular kind of organisation very well, and if you are that organisation you should stay.
1.1 The 6 Critical Questions
Answer these honestly. Write the answers down, because you will need them in vendor conversations anyway.
There is a real difference between “our version fell off support and the ELTS quote arrived”, “we cannot hire anyone who knows TypoScript”, and “marketing waits three weeks for a new kind of page section”. The first is a budget conversation with a deadline. The second is a talent problem that gets worse every year. The third is architectural, and it is the one migration actually fixes.
Be specific, because the three lead to different projects. A support-cliff problem can sometimes be solved by upgrading rather than replatforming. A talent problem and a velocity problem usually cannot.
Find the version in the top left of the backend, then find out who is paying for support and how much. TYPO3 v14 LTS arrived in November 2025 and v13 LTS in January 2024, so anything below that is either on ELTS or unsupported.
The number matters because it is the honest comparison against a migration budget. ELTS for v12.4 runs at €3,200 per licence per year, with v11 and v10 at €2,800. It is licensed per instance, so an estate of separate installations multiplies it, and it buys security and compatibility updates rather than features. You are paying to stand still.
This is the most useful number in the whole assessment, and almost nobody has it to hand. Count the custom CType values registered against tt_content, then count how many pages actually use each one.
The count drives the estimate because each custom content element is a small build of its own, shipped in an extension with its own field definitions and template, and each one needs a Gutenberg block equivalent. How it was built varies by version: older elements usually carry a TCA override, TypoScript and a Fluid template, while v13 onwards can define the same thing in YAML through Content Blocks. Teams are routinely surprised twice: first by how many accumulated, then by how few are still in real use.
TYPO3 is built to hold a lot in one place. Count the entries in config/sites/, the languages configured under each, and the domains pointing at the installation.
This is the single biggest fork in the road. One site in one language is a straightforward project. Twelve sites in six languages is a WordPress Multisite architecture decision, a multilingual plugin decision, and a governance decision, made before anyone writes an extraction script.
Include the migration, the ELTS or hosting you will still be paying during the transition, internal time, and training. If the number you have in mind is below $75,000, a full enterprise migration will not fit, and you should be scoping a phased move or a narrower one.
Support-driven deadlines are the most common here and the most dangerous, because they compress discovery and QA, which are the two phases that determine whether anyone judges the migration a success. One more year of ELTS is often cheaper than a rushed migration, and it is worth pricing both before committing to a date.
1.2 Interpreting Your Answers
Strong signals that migrating is right for you. Your version is off community support and the ELTS renewal keeps arriving. Nobody in the building writes TypoScript any more and the last person who did has left. Marketing waits on developers for routine layout changes. You are more than two major versions behind. You want a platform you can hire for in your own city.
Warning patterns that mean you are not ready. Nobody owns the decision. The business outcome is written as “move off TYPO3” rather than as something measurable. Your custom extension inventory does not exist. Nobody can say how many sites and languages the installation actually serves.
Scenarios where staying put is the right call. If you are on v13 or v14, your extensions are maintained, you have TYPO3 engineers who are staying, and your governance requirements genuinely need page-level permissions across a large multi-site estate, TYPO3 is doing the job it was designed for and doing it without a licence fee. Migrating would cost you money and capability. We would rather say that now than nine months into a project.
1.3 The Go/No-Go Decision Tree
Five questions. Three or more “yes” answers means the case is real.
- Is your installation off community support, or will it be within twelve months?
- Is the TYPO3 knowledge in your organisation concentrated in one or two people?
- Do routine layout changes require a developer, an extension change and a deploy?
- Are you more than two major versions behind current?
- Is there a named executive sponsor with budget authority who wants this to happen?
If you answered no to question five, stop. Migrations without a sponsor stall in month three, and a stalled migration costs more than never starting.
PART 2: Understanding Your Migration Complexity
Complexity on a TYPO3 migration comes from two places: how much of your site is custom extension code, and how many sites and languages sit inside the installation. Raw content volume matters less than people expect.
2.1 The Migration Complexity Scale
TYPO3 sits in the open-source and enterprise platform category rather than the SaaS one, so the full CMS migration cost scale applies. The reason is specific: custom extensions, TypoScript configuration and Fluid templates are application code, and application code has to be read, understood and replaced rather than exported.
Simple Migration (8-14 weeks, $75K-$200K)
Under 5,000 content records, one site, one or two languages, mostly stock content elements from fluid_styled_content, and fewer than five integrations. In practice this describes a corporate site or a resource centre.
Moderate Migration (14-24 weeks, $200K-$450K)
Between 5,000 and 50,000 records, several sites or languages in one installation, a working set of custom content elements, five to fifteen integrations, and a handful of in-house extensions nobody has documented. Most TYPO3 migrations land here.
High Complexity Migration (24-40+ weeks, $450K-$1M+)
Over 50,000 records, a large multi-site estate, extensive localisation, custom Extbase applications doing real business logic in the experience layer, or a regulated or public-sector governance model. If your TYPO3 installation is effectively an application rather than a website, you are here.
2.2 What Adds Time and Cost
Five factors move a TYPO3 estimate more than anything else.
Every custom content element in TYPO3 is a small development project of its own. Adding one means registering a CType, overriding the TCA on tt_content, writing TypoScript and building a Fluid template. Each one needs a Gutenberg block equivalent on the other side. This is the largest single line in most TYPO3 estimates.
Third-party extensions from the TER have WordPress equivalents. In-house Extbase extensions do not, and they are where the business logic hides. Every extension needs an owner, a decision, and in many cases a rewrite against a different framework.
One TYPO3 installation can serve many sites and languages, which is a strength right up until you have to take it apart. Each site in config/sites/ carries its own languages, routing and fallback behaviour, and every one of those decisions has to be remade in WordPress.
The native Import/Export module was built to move page branches between TYPO3 environments. Past a certain size the practical route is scripted extraction against the database, and that is engineering work with its own testing cycle rather than a button you press.
URL structure in TYPO3 lives in route enhancers inside the site configuration, and older installations often carry legacy patterns from RealURL that were never cleaned up. Your redirect map has to be derived from the routing rules as well as from the page tree.
2.3 The 3 Hidden Costs That Wreck Budgets
Every migration budget we have reviewed underestimates the same three line items. They are not exotic risks. They are predictable work that vendors leave out of proposals because including them makes the quote look worse than the competition’s.
What it actually costs: $50,000 to $100,000.
The technical migration moves records. It does not move the mental model your editors built over years of working in the page tree. Those are separate problems, and the second surfaces three weeks after launch when publishing throughput has halved.
There is a specific advantage here that other migrations do not have. TYPO3 editors already build pages by stacking content elements in a column, which is how the WordPress block editor works, so the conceptual leap is small. What changes is that the page tree becomes a flatter structure with taxonomies doing some of the work hierarchy used to do, and that is where the training time goes.
Budget for structured workshops with your editorial leads before any content moves, field-by-field mapping documentation, and two rounds of hands-on training after launch rather than a single handover.
What it actually costs: $40,000 to $75,000. What it costs to skip: $150,000 to $500,000 in lost organic traffic value.
TYPO3 makes this harder than average for two reasons. URL structure is generated by route enhancers rather than stored as a field you can export, and installations that have been through several major versions often carry three generations of URL patterns still resolving through redirects nobody documented.
The work is a full crawl of the live site, an export of every URL that has received organic traffic or an external link in the last two years, a one-to-one redirect map with no chains, and monitoring for at least ninety days after cutover with someone watching. Our growth services team runs this as a parallel workstream on enterprise migrations.
What it actually costs: $55,000 to $115,000.
TYPO3 does not store a file path on a content record. The File Abstraction Layer holds files in sys_file, their metadata in sys_file_metadata, and every use of a file in sys_file_reference. Copying the fileadmin folder moves the bytes and none of the meaning.
The cost sits in reconciliation rather than transfer. Every reference record has to be resolved to a content record, alt text and captions carried across from the metadata table, and rendition strategy rebuilt on the WordPress side. Teams that discover this after content migration has run end up doing the whole thing twice.
2.4 Migration Readiness Checklist
Work through this before you talk to vendors. Every unchecked box is either a question you cannot answer in a scoping call or a cost that will appear later.
Strategic Readiness
- The business outcome is written down and is not “move off TYPO3”
- Executive sponsor named, with budget authority
- Success metrics agreed and currently measurable
- A decision has been made about whether this is a replatform or a redesign
- The cost of doing nothing has been calculated, including ELTS renewals across every instance
Content Readiness
- Record counts known per site, per language and per content type
- Every custom CType inventoried, with the pages that use it and how often
- Translation mode identified per site: connected or free
- Content that will not be migrated identified and signed off
- Editorial workflow documented as it actually runs, not as the policy describes it
Technical Readiness
- TYPO3 version confirmed, with its support status and ELTS cost
- Every extension listed, marked as TER, in-house or abandoned, with a keep, rebuild or drop decision
- Site configurations exported, with languages, fallbacks and route enhancers documented
- Authentication and identity approach decided
- Hosting decision made
Team Readiness
- Internal time commitment estimated honestly and cleared with those people’s managers
- Your TYPO3 developer’s time specifically budgeted, because nobody else can read the extensions
- Training plan budgeted
- Post-launch ownership assigned
Risk Management
- Rollback plan defined
- Content freeze window agreed with the business
- Launch window avoids your peak trading or publishing period
- Legal and compliance have reviewed the plan
2.5 Timeline Reality Check
Most engagements run to the shape below. Discovery and QA are the phases compressed under deadline pressure, and the two that determine how the migration is judged six months later.
Simple migration: 8-14 weeks. Two to three weeks discovery, CType inventory and extraction build. Two weeks environment and theme setup. Two to three weeks content migration and verification. Two weeks QA and redirect testing. One week launch. One to two weeks training and handover.
Moderate migration: 14-24 weeks. Three to four weeks discovery, including the site and language architecture decision and the CType-to-block workshops. Three to four weeks environment, theme and block development. Four to six weeks content migration, run at least three times before the real one. Three to four weeks QA, redirect and integration testing. One to two weeks launch. Two to three weeks training and support.
High complexity migration: 24-40+ weeks. Six to eight weeks discovery across every site, language and extension. Six to eight weeks build. Eight to twelve weeks content migration, phased by site or brand. Six to eight weeks QA across every integration and locale. Two to three weeks phased launch. Four or more weeks training.
PART 3: Choosing the Right Migration Partner
Who runs this matters more than which platform you land on. The section below applies to any enterprise migration, with the TYPO3-specific tells called out.
3.1 Red Flags in Vendor Evaluation
Three of the five below apply to any enterprise migration. Two are specific to what a vendor should be asking about a TYPO3 source.
A vendor who quotes a TYPO3 migration without asking for your extension list, which ones are in-house, and how many custom content elements you run is quoting a template. Those three answers move the estimate more than your record count does, and a partner who has not asked has not priced your project.
The Import/Export module exists, and at enterprise volume it is not the mechanism. If a vendor describes extraction as running an export without mentioning TCA, sys_file_reference or scripted database extraction, they have not done this before. Ask what happens to a content element type they have never seen.
You want to hear about scripted, repeatable, re-runnable migration with a verification step, and an honest answer about what will be handled manually. “We have proprietary tools” is not an answer. Ask to see a migration report from a previous project.
Find out who does the work, where they sit, and whether the people in the pitch are the people on the project. Ask for named roles and allocation percentages. A team of three at 30% allocation is not a team of three.
If redirect strategy, crawl comparison and post-launch rank monitoring do not come up unprompted, they are not in the plan. On a TYPO3 source this is worse than usual, because URL structure is generated by routing rules rather than stored on the record.
3.2 Questions to Ask Every Vendor
Ask all of these. The pattern across the answers matters more than any single response.
- How many migrations from TYPO3 specifically have you completed?
- Have you read TCA to work out a content model before, and can we see how you documented it?
- Which of those projects went over schedule, and what caused it?
- Can we speak to a client whose project did not go smoothly?
- Walk us through your process from kickoff to ninety days post-launch.
- How do you translate a library of content element types into blocks without simply copying it?
- How do you handle content that does not map cleanly to the new model?
- How many times will you run the migration before the real one?
- Who exactly works on this, and what percentage of their time do we get?
- Who is our day-to-day contact, and who handles escalation?
- Do you have people who can read PHP and Fluid, or is that our job?
- What does support look like in the first ninety days after launch?
- What is your rollback plan?
- What have you got wrong on a previous migration, and what changed as a result?
- How do you handle scope changes mid-project?
- What do you need from us, and what happens if we are late delivering it?
3.3 The Reference Check That Actually Matters
Vendors supply references who will say good things. Ask these five questions and listen for hesitation rather than for praise.
- What did the final invoice look like against the original quote, and what caused the gap?
- What did you have to do internally that you had not planned for?
- How long after launch did your team stop finding problems?
- If you were doing it again with the same vendor, what would you change about how you worked with them?
- Who on their team made the difference, and are they still there?
The fourth question produces the most honest answers, because it invites criticism without asking anyone to criticise.
3.4 The WordPress VIP Partner Advantage
WordPress VIP is Automattic’s enterprise platform, and its partner tiers are not self-certifications. Partners are selected by Automattic and assessed on delivered work.
The tier matters in three situations. At high scale, VIP partners have platform access and escalation paths that independent agencies do not. Under compliance obligations, VIP’s infrastructure carries the certifications and audit trails that security reviews ask for. And on unusual architectures, which describes most large TYPO3 estates, VIP partners have seen the edge cases because Automattic routes the difficult projects to them.
Multidots is a WordPress VIP Premier Partner, the highest tier, with 1000+ platform migrations across 17+ years of WordPress work. We are the 5th largest WordPress contributor globally, SOC 2 Type II compliant, and an Inc. 5000 company.
If you are not operating at that scale, you may not need a VIP partner, and a good vendor will tell you so.
3.5 Build vs. Buy vs. Partner Decision Matrix
Three routes exist, and the right one depends more on your internal capacity than on your budget. The comparison below assumes a moderate-complexity migration.
| Factor | Build in-house | Buy a template solution | Partner with a specialist |
|---|---|---|---|
| Upfront cost | Lowest on paper | Low | Highest |
| True cost | Highest, once internal time is counted | Moderate, once customisation is counted | Predictable |
| Timeline | Longest, competes with other work | Fastest to a basic site | 8-40 weeks depending on tier |
| Risk of failure | Highest | Moderate | Lowest |
| Knowledge retained internally | Highest | Lowest | Depends on the handover clause |
| Fit to your actual workflow | Best, if you finish | Worst | Good |
| Suits you when | You have WordPress engineers idle and no deadline | You run one site in one language | Extensions, locales, or SEO stakes are material |
A hybrid is under-used and works particularly well here, because the person who can read your extensions already works for you. A specialist runs the migration and the architecture, your TYPO3 developer documents what the code actually does, and your team owns the platform afterwards. Our staff augmentation model exists for exactly this.
3.6 What Great Partners Do Differently
The differences show up early, usually in the first two conversations, and they are behavioural rather than technical.
The most valuable thing a partner does early is disagree with you. On a TYPO3 migration the useful disagreement is usually about the content element library: you almost certainly should not rebuild all of it, and a partner who agrees to copy it one for one is selling you work rather than judgement.
An honest partner gives you a range, tells you what moves it, and tells you which parts of the estimate they are least confident about. Certainty this early is a sales technique.
Ask what documentation you get. It should include content model decisions and the reasoning behind them, the redirect map, the extension inventory, deployment runbooks, and editorial guides. If documentation is a final-phase line item, it will be written by someone who has already moved on.
The best partners build so you can maintain it without them, and they say so up front. That means standard patterns over clever ones, real handover, and no dependency on proprietary tooling you cannot access after the contract ends. A partner who makes themselves difficult to leave has told you something about their confidence in the work.
3.7 Red Flags vs. Green Lights: Quick Reference
Use this as a scoring sheet during vendor conversations rather than reading it once.
| Area | Red flag | Green light |
|---|---|---|
| Scoping | Quotes before seeing your extension list | Asks for CType counts and usage per page |
| Extraction | Describes the export module as sufficient | Prices scripted extraction guided by TCA |
| Architecture | Multisite question not raised | Sites and languages mapped in the first call |
| Timeline | Single confident date | Range, with the variables named |
| Content | “We have proprietary tools” | Describes a scripted, re-runnable process with verification |
| SEO | Comes up only when you raise it | Raised unprompted, with route enhancers in scope |
| Risk | No rollback discussion | Rollback plan and a content freeze window |
| References | Only happy clients offered | Offers a client whose project was difficult |
3.8 Making the Final Decision
Score each vendor from 1 to 5 against the criteria below and weight the results. The exercise is useful mainly because it forces you to separate how much you liked the pitch from how the proposal actually reads.
Technical Capability (25% weight):
Demonstrated TYPO3 migration experience, WordPress depth at enterprise scale, and people who can read PHP and Fluid without your help.
Methodology and Process (20% weight):
A described process rather than a described outcome, with QA, verification and rollback in it.
Team and Communication (20% weight):
Named people, sensible allocation, a single point of contact, and a clear escalation path.
References and Track Record (20% weight):
Comparable projects in scale and sector, and references who answer hard questions without hedging. Ask to see case studies with numbers in them.
Value and Transparency (15% weight):
Line-item pricing, explicit exclusions, and an honest statement of what is not included. The cheapest proposal is rarely the lowest total cost, and the most expensive is not automatically the safest.
PART 4: Why You Should Migrate from TYPO3 to WordPress
This is the part to send to whoever signs off the budget. It covers the strategic argument, the benefits by team, how the cost model differs, the constraints TYPO3 documents itself, and the objections you will hear internally.
4.1 The Business Case for Migration
The case against TYPO3 is not that it is expensive to licence, and any business case built on licence cost will fall apart in the first finance review. TYPO3 is GPL and free. So is WordPress.
The case is that your money goes somewhere the invoice does not show it. It goes into a maintenance treadmill that never ends and a talent market that keeps shrinking. Every major version brings an upgrade project, every upgrade project brings extension compatibility work, and every year the pool of people who can do that work gets smaller. TYPO3 is used by 0.4% of all websites and 0.5% of sites whose CMS is known. WordPress runs 40.7% of all websites and 58.9% of those with a known CMS. When your TypoScript developer resigns, those two numbers are the whole story. Our migration case studies are mostly organisations that reached that point.
The second half of the case is velocity. A new kind of page section in TYPO3 requires an extension, a TCA override, TypoScript and a Fluid template, which means a developer and a deploy by design. For an organisation shipping campaigns weekly, that coupling is the constraint on how fast marketing can move.
WordPress addresses both. Editorial and presentation live in one place, marketing ships new layouts without a deploy, and you hire from the largest CMS developer pool in the world. If you still need API delivery, headless WordPress provides REST and GraphQL endpoints from core rather than from a community extension.
4.2 Benefits of Migrating from TYPO3 to WordPress
The gains land differently depending on which team you ask, which is worth knowing before you build a business case for an executive audience.
| Technical team | Editorial team | Marketing team | |
|---|---|---|---|
| Immediate gain | No upgrade treadmill and no support cliff | New page sections without a developer | Ship campaigns without a deploy |
| Tooling | Standard PHP with no platform-specific configuration language | Block editor with patterns and revision history | Native SEO tooling, analytics of your choice |
| Control | Own the hosting, the code, and the release pipeline | Roles and capabilities you define yourself | Direct control of URLs, metadata and schema |
| Talent | Hire from the largest CMS developer pool in the world | Onboard new editors in hours | Deep agency and freelancer market |
| Long-term | REST and GraphQL in core, not in an extension | Editorial workflow that fits how you work | Growth work on your own stack |
For Technical Teams
The upgrade treadmill changes shape. WordPress core updates are incremental, and preserving backward compatibility across versions is a long-standing practice of the project, so you are not planning a project around every major version and auditing every extension for compatibility first. You also stop maintaining knowledge of a configuration language that exists in one product. TypoScript is described in TYPO3’s own documentation as “not a programming language but a means of configuring the website”, and every hour your team spends learning it is an hour that transfers nowhere else.
For Editorial Teams
The conceptual model barely changes, because stacking blocks on a page is stacking content elements in a column with a different name. What changes is who can create a new one. Patterns let your team assemble approved arrangements without engineering, and preview, revisions and scheduling come as standard.
For Marketing Teams
You control URL structure, metadata, schema markup and sitemaps directly rather than through routing rules in a YAML file a developer owns. Landing pages ship without engineering. Analytics is whatever you choose, and AI implementation work sits on your own stack rather than waiting for an extension to be updated.
4.3 Cost Comparison: TYPO3 vs WordPress
Both platforms are free, so the comparison is the shape of the cost rather than a licence line. The table below sets out where the money actually goes.
| TYPO3 | Enterprise WordPress | |
|---|---|---|
| Licence | None, GPL | None, GPL |
| Staying on a supported version | ELTS at €2,800 to €3,200 per licence per year once free support ends | Core updates are free and incremental |
| Billing unit for support | Per instance, so an estate multiplies it | Not applicable |
| Major version upgrades | A project each time, with extension compatibility work | Incremental, with backward compatibility preserved as a rule |
| Content model changes | Extension, TCA override, TypoScript, Fluid template | Block or field registration, often no deploy |
| Talent market | 0.4% of the web, concentrated in one region | 40.7% of the web, global |
| Extension ecosystem | Thousands of extensions in the TER | 67,000+ plugins in the WordPress directory |
| API delivery | Community extension plus a separate front end | REST and GraphQL in core |
| Hosting | Your main recurring cost | Your main recurring cost |
Read that table carefully before using it, because the top line is identical as neither platform charges for the software. The rows that matter are the second, the fourth and the sixth: a support bill that only appears once you fall behind, an upgrade cycle that consumes engineering capacity on a schedule someone else sets, and a hiring market that gets harder every year.
4.4 Why TYPO3 Might Be Holding You Back
Four constraints below are documented by TYPO3.
TYPO3’s documentation states that the core contains upgrade wizards for two consecutive major versions, and that installations needing to move across more than two majors at once require a third-party extension, wapplersystems/core-upgrader, to migrate the data. Fall three versions behind and the platform can no longer carry your content forward on its own. This is the mechanism that turns a deferred upgrade into a replatform decision.
Community support for v12.4 expired in April 2026. Staying secure after that costs €3,200 per licence per year before discounts, renewed annually, for security and compatibility updates rather than features. It is licensed per instance, so an organisation running several installations pays several times, and the clock restarts with every version.
TCA is described in the documentation as “a layer on top of the database tables that TYPO3 can operate on”, and it defines which tables the backend can see at all. Tables without a TCA entry are “invisible” to the backend. The practical consequence is that nobody can tell you what your content model is by looking at the database. It has to be read out of PHP, which is why a TYPO3 discovery phase takes longer than the record count suggests.
Adding a content element type means creating an extension, registering a CType, overriding the TCA on tt_content, writing TypoScript and building a Fluid template. There is no path where an editor adds a new kind of section. That is a deliberate design choice in favour of governance, and it is also the reason marketing teams file tickets for layout changes.
4.5 Common Concerns Addressed
These are the eight objections that come up most often inside organisations weighing this move, phrased the way people actually raise them.
The saving is in maintenance and hiring. Add up ELTS renewals across every instance, the engineering weeks each major upgrade consumes, and what you pay TYPO3-specific contractors against what you would pay WordPress developers. For some organisations that total still favours staying. For most, the upgrade line alone changes the answer.
Yes, though assembled differently. Multisite gives you one network, one codebase and one place to manage updates and users. Roles and capabilities are defined in code, so you can build the exact permission set you have today rather than picking from a fixed list. The honest difference is that TYPO3 ships this in core while WordPress assembles it from core, configuration and one or two plugins.
Workspaces are one of TYPO3’s genuinely strong features and it would be misleading to wave that away. WordPress has drafts, revisions and scheduling in core, and editorial approval workflows come from a plugin such as PublishPress rather than from the platform. If a multi-stage approval chain with previewable staged changes is central to how you publish, budget that as a workstream and test it before cutover.
The code, yes. The design and the content model, no. Fluid templates translate into block templates reasonably directly because both describe how a piece of content renders, and the audit usually finds far fewer distinct layouts than the template count suggests. What does not carry over is TypoScript itself, which has no equivalent because WordPress does not need a separate configuration language.
Yes, and that is the right way to use it. ELTS buys you a defined window, and running a migration inside a window you have already paid for is far better than running one against a security deadline. Start discovery now, launch before the coverage ends, and do not renew.
Enterprise WordPress on managed hosting carries the certifications enterprise security reviews ask for. Multidots is SOC 2 Type II compliant, and WordPress VIP maintains enterprise infrastructure certifications. The incidents WordPress is known for trace almost entirely to outdated plugins and weak credentials on unmanaged installs, both of which are process problems that managed services solve. It is also worth noting the other side: an unsupported TYPO3 version with no ELTS is a documented security position, not a neutral one.
It is a real cost and it belongs in the budget, though it is smaller here than on most migrations. Editors who build pages by stacking content elements are already doing what the block editor asks of them. Most teams need days rather than weeks. Spend the training time on what genuinely changes, which is navigating a flatter structure where taxonomies do some of the work the page tree used to do.
WordPress runs a large share of the highest-traffic publishing operations on the web, and our own client list includes Rolling Stone, SiriusXM, and Storyful (NewsCorp). There is no documented URL or content-type ceiling to design around. Capacity comes from how the application is architected and how the infrastructure is sized, and at this scale both have to be designed deliberately.
PART 5: How to Migrate from TYPO3 to WordPress
Six steps, running from strategy through to the maintenance model you will live with afterwards. Steps 1 and 2 are where most of the risk is removed, and they are the two most often compressed when a deadline tightens.
Step 1: High-Level Migration Strategy
Everything in this step happens before a single record moves. Rushing it is the most reliable way to make the later steps expensive.
1.1 When should we migrate?
The best window is inside ELTS coverage you have already bought rather than against the month it expires. Buying one more year to get the timeline right is usually the correct trade, because support-driven deadlines compress discovery and QA. Avoid launching into your peak publishing period, and keep the TYPO3 environment running through cutover as a rollback path.
1.2 Which CMS should we migrate to?
WordPress is the right answer for most organisations leaving TYPO3, and it is worth saying when it is not. If your requirement is structured content feeding several applications and you have a front-end team who will own that layer, a headless platform such as Sanity may fit better. If it is a public website with an editorial team behind it, WordPress wins on editorial autonomy, talent availability and total cost. Our TYPO3 vs WordPress comparison covers that feature by feature.
1.3 Design strategy: refresh or replicate?
Replicating the current design on a WordPress theme makes QA straightforward, since every page has an obvious correct answer. Redesigning during migration doubles the things that can be wrong at once and makes it impossible to tell whether a traffic drop came from the migration or the design. If a redesign is needed, ship on a close replica first and redesign six to eight weeks later.
Pro tip: if stakeholders push for a redesign, agree the split explicitly and put both dates in the plan. “We will redesign later” without a date means the replica ships and the redesign never happens.
1.4 TYPO3 feature audit and WordPress mapping
Before scoping anything, map the concepts. The table below is the standard mapping and the right starting point for the workshop with your editorial leads.
| TYPO3 concept | What it does | WordPress equivalent |
|---|---|---|
| Page tree (pages) | Hierarchical records forming the site structure | Pages with parents, or a hierarchical post type |
| Content element (tt_content) | A block of content placed in a column on a page | Gutenberg block |
| CType | The type of a content element | Block type |
| TCA | PHP array defining which tables and fields the backend can see | Post type registration plus registered fields or ACF |
| Extension (EXT:) | Packaged functionality from the TER or built in-house | Plugin |
| TypoScript | Configuration language controlling output and behaviour | Theme configuration and template hierarchy |
| Fluid template | Renders content elements and pages | Theme template or block template |
| Sys folder | Page type storing records that never render as a page | Storage post type with no public URL |
| FAL (sys_file_reference) | Links files to content, with metadata held separately | Media library and attachment records |
| Site configuration | Domains, languages and routing for one site | Site settings, permalinks, multilingual plugin |
| Site language and l10n_parent | A language variant and its link to the source record | Translation pair in a multilingual plugin |
| Backend user group | Permissions, page mounts and file mounts | Role plus capabilities |
| Workspace | Versioned draft changes with an approval step | Draft, revisions, editorial workflow plugin |
| sys_category | Category records assignable to content | Category or custom taxonomy |
| Frontend user group (fe_group) | Restricts content to logged-in groups | Membership or role-based restriction |
The TypoScript row is the one to discuss rather than map. It has no equivalent, so the work is deciding which behaviours it controls today and where each of those lands.
1.5 Third-party integration planning
Every integration needs an owner, a renewal date and a decision. The categories below cover most TYPO3 implementations.
| Category | TYPO3 side today | WordPress replacement |
|---|---|---|
| News and articles | EXT:news | Posts with custom taxonomies |
| Site search | EXT:solr against Apache Solr | ElasticPress or Algolia |
| Forms | EXT:form system extension | Gravity Forms or Fluent Forms |
| Commerce | Aimeos or a commerce extension | WooCommerce, or keep the engine headless |
| Digital asset management | FAL storage driver to an external DAM | Media library, or keep the DAM connected |
| Identity and SSO | SAML or OIDC extension | SAML or OIDC plugin against the same provider |
| Analytics | Matomo or Google Analytics extension | GA4 or Matomo, unchanged |
| Headless delivery | Community headless extension plus a Nuxt front end | REST and GraphQL endpoints in core |
Pro tip: sort your extension list into three piles before you talk to anyone: from the TER and maintained, from the TER and abandoned, and written in-house. The third pile is where your discovery budget goes, because nobody outside your organisation can tell you what that code does.
1.6 Enterprise hosting strategy
Hosting is where WordPress performance is won or lost. Compare on the dimensions below rather than on headline price.
| Host | Best suited to | Notable |
|---|---|---|
| WordPress VIP | Highest-traffic publishing, regulated industries | Automattic’s enterprise platform, strongest compliance posture |
| WP Engine | Mid-to-large enterprise | Broad feature set, strong developer tooling |
| Pantheon | Teams wanting strict environment workflows | Git-based deployment pipeline |
| Kinsta | Performance-focused mid-market | Google Cloud infrastructure |
| Pagely | Enterprise with custom infrastructure needs | AWS-based, high customisation |
For teams leaving TYPO3 the deciding factors are usually data residency, since many TYPO3 estates are European, and whether the deployment workflow matches what your engineers expect from Composer-based releases.
1.7 Migration team: internal vs. external expertise
You need four things: WordPress engineering, someone who can read your TYPO3 extensions, editorial decision-making, and project management. The middle two must come from inside your organisation.
Budget explicit time from whoever maintains the installation. That person is more central here than on most migrations, because the content model is in PHP and the extensions are undocumented, so they are the only route to knowing what the site does. If WordPress engineering capacity is the gap, embedding vetted WordPress engineers with your team is usually faster than hiring for a fixed-length project.
Step 2: Pre-Migration Preparation
Preparation is where you build the reference points you will be measured against later: what you had, where it lived, and how it performed.
2.1 Full backup strategy
Take a full database dump and a copy of the entire file system, including fileadmin, config/sites/ and every extension directory. The site configurations and the extension code matter as much as the database, because between them they hold the content model. Verify the backup by restoring it into a working environment and loading a sample of pages. An unverified backup is a hope rather than a plan.
2.2 Content inventory and audit
Count everything, by site, by language and by content type. Then flag three categories: content that migrates as-is, content that migrates with changes, and content that does not migrate.
The third is usually larger than expected and represents real savings, because installations that have run for a decade accumulate archives nobody has had a reason to prune. Pull the analytics first and get sign-off from content owners. Across our platform migration work, the archive-or-drop decision is the cheapest lever for bringing a quote down.
Pro tip: inventory content element types by usage, not just by existence. Query tt_content grouped by CType and count the rows. Teams routinely find that a third of the custom types appear on fewer than five pages, and those are candidates for consolidation rather than translation.
2.3 SEO and performance baseline
Capture where you stand before you change anything. Crawl the full site and export every URL, pull twenty-four months of organic traffic and ranking data, record Core Web Vitals from field data, and export your backlink profile so you know which URLs carry external authority.
On TYPO3, add one step the other guides do not need: export the route enhancer configuration from every site YAML file and document any legacy redirect rules still running. Your URL structure is generated rather than stored, so it will not appear in a content export.
2.4 TYPO3 content structure analysis
Go deeper than the inventory. Read the TCA for every table in play and document each field, its type, whether it is required, and what editors actually put in it against what it was designed for. Those two diverge, and that is where migration scripts break.
Then check translation mode per site. TYPO3 offers connected mode, where a translated record links to its source through l10n_parent, and free mode, where content was copied with no link at all. Free-mode translations carry no relationship for a script to follow, so pairs have to be reconstructed by matching or by hand. Establish the mode per site before anyone estimates the multilingual workstream.
Step 3: WordPress Environment Setup
Four architectural decisions here shape the next three years. Make them before development starts, because reversing any of them later is a project in itself.
3.1 Architecture decision: traditional vs. headless WordPress
Traditional WordPress serves the front end itself. Headless serves content over REST or GraphQL into a separate front end. Traditional is the right default for most TYPO3 estates: simpler to run, cheaper to maintain, live preview without extra engineering, and fast enough for almost every use case when hosted properly. Choose headless for a specific reason, such as an existing JavaScript front end you are keeping, several front ends consuming one content source, or a front-end team who will own that layer long term.
Pro tip: if you already run a decoupled TYPO3 setup through a community headless extension, note what changes. In WordPress the API is in core, so the delivery layer stops being something you maintain separately.
3.2 Multisite vs. single site strategy
This is the decision that matters most for TYPO3 teams, because one installation serving many sites maps onto WordPress Multisite unusually well. One network, one codebase, one design system, one place to manage updates and users, which is close to what you have today.
Single site is better when properties have materially different requirements, separate teams, or independent release schedules. The coupling in Multisite is real: a plugin update affects every site at once. Decide before development starts.
3.3 User roles and workflow configuration
TYPO3 governance is usually more granular than teams actually need, because page-level permissions were available so they got used. Treat this as a design exercise rather than a mapping one, and rebuild the permissions your workflow requires instead of the ones that accumulated.
| Function | WordPress role | Typical capability |
|---|---|---|
| Platform owner, plugin and user management | Administrator | Everything, kept to two or three people |
| Editorial lead, publishes and manages others’ content | Editor | Publish and edit all content |
| Staff writer, publishes own work | Author | Publish and edit own content |
| Contributor or agency, drafts only | Contributor | Write, cannot publish |
| Legal or compliance reviewer | Custom role | Read and comment, no edit |
Most enterprise teams need one or two custom roles beyond the defaults. If you are replacing workspaces, add approval workflows with a plugin such as PublishPress rather than building from scratch, and test the chain with real editors before cutover.
3.4 Custom Gutenberg blocks and page templates
Your CType inventory from Step 2.2 is the specification, and the usage data is what stops you copying it wholesale. The goal is a smaller library of well-constrained blocks that make the right layout easy and the wrong layout impossible. Three content element types that differ only in background colour are one block with a setting.
Pro tip: build block patterns as well as blocks. Patterns are the thing your editors have been filing tickets for, since they let the team assemble approved arrangements without anyone writing an extension.
3.5 Essential plugin stack for enterprise
Keep the plugin count low and the quality high. Every plugin is a dependency, a security surface and an update obligation. A typical enterprise WordPress stack covers SEO, security, caching, forms, editorial workflow, media optimisation, analytics and custom fields. Choose plugins with a commercial entity behind them, a public security disclosure process, and a release history suggesting they will still be maintained in three years.
Step 4: Migration Execution and Launch
The execution phase is mechanical if the first three steps were done properly. Run everything more than once, and treat the first two runs as tests rather than attempts.
4.1 Content migration process
Run this in four phases, at least three times before the real one.
Phase 1, Extract from TYPO3. For a single site branch the Import/Export module is viable. At volume, script against the database instead: pages for structure, tt_content for content elements, sys_file_reference and sys_file_metadata for assets, plus the extension tables your TCA reading identified. Run long-running extraction from the command line to avoid web-request timeouts and to get better control over batch processing.
Phase 2, Transformation. Map pages to post types and content elements to block markup, using the CType-to-block decisions from Step 3.4. Rebuild the page hierarchy, resolve l10n_parent relationships into translation pairs, resolve file references, and rewrite internal links. This is where the TCA documentation from Step 2.4 earns its cost.
Phase 3, Import into WordPress. Load assets first, then pages, then content, so references resolve in order. Run in batches with logging on every record, and make every run idempotent so a failed batch can be rerun without duplicating.
Phase 4, Verification. Compare counts by site, language and content type against the source. Spot-check rendered output, especially pages built from custom content elements, and validate that every internal link and asset reference resolves. Then rebuild backend permissions as WordPress roles, which do not come across.
4.2 Media and digital asset migration
Copying fileadmin moves the files and none of the relationships. Every asset is connected to content through sys_file_reference, and its alt text, title and caption live in sys_file_metadata rather than on the file. Resolve both tables before importing, or you will land a media library with no alt text and content with no images. Preserve filenames where possible, and configure image sizes on the WordPress side deliberately rather than migrating every rendition TYPO3 generated.
4.3 URL mapping and SEO preservation
Build a one-to-one redirect map from the crawl captured in Step 2.3 and the route enhancer configuration you exported alongside it. No chains, and no wildcards standing in for pages that deserve a specific destination. Every URL that has received organic traffic or an external link in the last twenty-four months needs an explicit entry. Installations that have been through several major versions need particular attention, because they often carry legacy URL patterns from RealURL still resolving through rules nobody documented.
Migrate metadata, canonical tags and structured data alongside the content rather than treating them as a post-launch task. Submit a new sitemap on day one and keep Search Console open for ninety days. On enterprise migrations we run this as a dedicated growth workstream rather than as a developer task.
Pro tip: test the redirect map against your live crawl before launch. A scripted check that requests every old URL and asserts a single 301 to a 200 takes an hour to write and catches the errors that would otherwise cost you a quarter of organic traffic.
4.4 Pre-launch testing and quality assurance
Test in four passes. Functional, covering every template, form and integration. Content, against a meaningful sample of the source, with particular attention to translated pages and pages built from custom content elements. Performance, against the Step 2.3 baseline. Access, covering every role and gated tier. Then get editorial sign-off from the people who will use the system, doing real tasks, before launch.
4.5 Go-live strategy and monitoring
Agree a content freeze window with the business and hold it. Run the final migration during the freeze, cut DNS, and keep the TYPO3 environment intact for at least thirty days as a rollback path. If nobody internally is on call for that period, put a managed services retainer in place before cutover.
Watch error rates, 404s, Core Web Vitals and organic traffic daily for two weeks and weekly for three months. Expect a small ranking fluctuation in the first two to four weeks, and investigate if it has not recovered by week eight.
Step 5: Post-Migration Optimization and Team Training
Launch is the midpoint. What happens in the eight weeks afterwards determines whether the migration is judged a success internally.
5.1 Performance optimization and monitoring
Compare like for like against the baseline: same pages, same connection profile, same time of day. Focus on Core Web Vitals and treat field data from real users as the number that matters. Set page-weight budgets by template and enforce them in the build, because regressions arrive gradually through content and third-party scripts rather than through code. We scope performance optimization into the engagement rather than after it, and automate the alerting rather than relying on spot checks.
5.2 Team training and workflow optimization
Training in the week before launch does not work, because people have nothing to attach it to. Run it in three passes: an orientation two to three weeks out so the interface is familiar, hands-on sessions in launch week doing real tasks in the real environment, and a follow-up two to four weeks after launch when people have accumulated questions.
TYPO3 editors adapt faster than most, because stacking blocks is what they already do. Spend the time on what actually changes: a flatter structure with taxonomies doing some of the work the page tree used to do, and the fact that they can now assemble arrangements nobody had to code first.
5.3 Long-term success strategy
The migration is a project. The platform is not. Name the owner before the project team disperses, agree an update and testing cadence, review plugins and performance quarterly, and give editors a route to request changes. Skip it and you end up two years later with an outdated install and nobody who remembers how it was built, which is usually the position you were in on TYPO3.
Step 6: Ongoing Maintenance and Monitoring
The platform needs an owner and a cadence, both agreed before the project team moves on.
6.1 WordPress update management
Handle updates with a process rather than with attention. Run them on staging first, on a fixed cadence, with automated smoke tests covering critical paths. Apply security releases quickly and everything else on the cadence. Keep a tested rollback path, version-control the codebase, and deploy through a pipeline rather than the admin interface.
Teams arriving from TYPO3 find this familiar, since Composer-based releases are already how they work. What changes is the scale: incremental updates on your schedule rather than a project every major version.
6.2 Performance and security monitoring
Monitor uptime, response time, Core Web Vitals from field data, error rates and failed login attempts. Alert on thresholds rather than reviewing dashboards, because nobody reviews dashboards. Run a firewall and malware scanning through Wordfence or Sucuri, enforce multi-factor authentication for anyone who can publish, keep administrator accounts minimal, and review access quarterly. Most incidents trace to an outdated plugin or a weak credential rather than to a platform vulnerability.
6.3 Maintenance service options
Three models are common. An internal team works when you have WordPress engineers and enough volume to keep them busy. A retained agency works when you need expertise without headcount. A hybrid, where your team handles content and an agency handles code, security and performance, is what most enterprise teams settle on. Multidots offers maintenance and support packages, along with dedicated developers for teams who want capacity rather than a managed service.
Ready to Explore Your Options?
If you are weighing a move from TYPO3 to WordPress, the useful next step is a conversation with someone who has done it before rather than another vendor deck.
Book a free 30-minute migration call. No pitch. We will look at your version, your extension list and your site and language count, tell you where the difficulty actually sits, and give you a realistic range. If migrating is the wrong call for you right now, we will say so.
Get a written migration assessment. Send us your site and a rough content inventory, and we will come back with a written view of complexity, timeline and the risks specific to your setup, usually within three business days.
Schedule a conversation with our migration experts, or read more about how we handle any CMS to WordPress migrations.
Frequently Asked Questions
Most engagements run 14 to 24 weeks for a moderate-complexity platform migration. Single-site installations with under 5,000 records and mostly stock content elements can complete in 8 to 14 weeks. Large multi-site, multi-language estates with heavy in-house extensions run 24 to 40 weeks or longer.
It changes the deadline rather than the duration. ELTS for v12.4 runs to 31 October 2027 for standard customers and 31 October 2028 for TYPO3 Partners, so work backwards from your coverage end and start discovery early enough to launch inside it. Migrating against a live security deadline is the version of this project that goes wrong.
Fluid templates translate into block templates reasonably directly, because both describe how one piece of content renders. TypoScript has no equivalent and is not carried across, since WordPress does not use a separate configuration language. Budget the translation as design work rather than as a port, and expect the audit to find far fewer distinct layouts than your template count suggests.
For a single page branch, the Import/Export module writes XML or T3D with assets in a separate folder. Above a few thousand records the practical route is scripted extraction against pages, tt_content, sys_file_reference and your extension tables, run from the command line so it is not bound by the PHP time limit. There is no maintained TYPO3 importer for WordPress, so budget engineering time for the extractor rather than assuming a plugin exists.
It lengthens it. TCA defines the model in PHP rather than in the database, and tables without a TCA entry are invisible to the backend, so nobody can tell you what your content is by reading the schema. Plan two to four weeks of discovery on a moderate migration purely to read TCA and document fields before anyone estimates the transformation work.
Usually yes, and this is the case where Multisite earns its complexity. One network gives you the shared codebase, shared design system and single administration point you have today. Budget two to four weeks for the multilingual setup on top, since translation relationships and language-specific URL structures both need explicit configuration.
Yes, and it is worth checking before anyone quotes. Connected-mode translations link back to their source record through l10n_parent, so a script can pair them automatically. Free-mode translations are copies with no link, so the pairs have to be reconstructed by matching or by hand. Establish the mode per site during Step 2.4, because a site that used free mode can add a week or more to the multilingual workstream.
Drafts, revisions and scheduling come from WordPress core, and multi-stage approval comes from an editorial workflow plugin such as PublishPress. It is assembled rather than built in, so if your approval chain is central to how you publish, treat it as a workstream with its own testing and get editors to run a real approval before cutover.
Expect a fluctuation in the first two to four weeks and a return to baseline by week six to eight, provided redirect mapping is done properly. TYPO3 makes this harder than average because URL structure comes from route enhancers rather than from a stored field, and long-lived installations often carry legacy patterns from RealURL. Budget $40,000 to $75,000 for this workstream.
Yes. WordPress runs a large share of the highest-traffic publishing operations on the web, and our own enterprise client list includes Rolling Stone, SiriusXM and Storyful. There is no documented URL or content-type limit to design around, and sites with hundreds of thousands of URLs are routine on enterprise hosting.
Your PHP developers transfer well, since WordPress is PHP and the deployment patterns are familiar from Composer-based TYPO3 work. What does not transfer is TypoScript, Fluid and Extbase knowledge, which has no equivalent to apply. Most teams either hire WordPress developers or retain an agency for the first year and bring the work in-house afterwards. Editors typically need days rather than weeks.
Phase it if you run several sites in one installation, more than 50,000 records, or multiple brands, since the sites give you natural phase boundaries. Migrate in one pass if you have a single site under about 20,000 records, because phasing adds coordination overhead and a period where content lives in two systems while you maintain both.
