Most teams do not go looking for a new CMS. They hit a wall.
For Salesforce CMS, that wall is usually one of three things. Your Experience Cloud site is approaching the platform’s route limit and nobody can tell you what happens next. Your licence renewal has arrived and the number has moved because your audience grew, not because you published more. Or your editorial team has stopped using the CMS properly, because getting a page live involves an admin, a developer, and a queue.
Let us be honest about something upfront. Migrating from Salesforce CMS to WordPress is not a simple platform swap, and anyone who tells you otherwise is selling something. Salesforce CMS sits inside a larger system that also holds your customer data, your marketing automation, and possibly your commerce. Pulling the content layer out of that without breaking the connections is real engineering work, and the export tooling is going to fight you.
This guide walks through the whole decision, including the parts where staying put is the right answer. It is built on what we have learned across 1000+ platform migrations.
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 Salesforce CMS to WordPress. Start here
- PART 5: How to Migrate from Salesforce CMS to WordPress. Start here
- Frequently Asked Questions. Start here
If you would rather talk it through than read the guide, you can schedule a free 30-minute consultation with one of our migration experts.
PART 1: Should You Really Migrate? The Decision Framework
Before scoping anything, work out whether the move is justified. Some organisations running Salesforce CMS should stay exactly where they are, and it is worth finding out early if you are one of them.
1.1 The 7 Critical Questions
Answer these honestly. Write the answers down, because you will need them in vendor conversations anyway.
Establish two things before you scope anything: whether your CMS workspaces are enhanced or non-enhanced, and whether your Experience Cloud site is Aura, LWR, or enhanced LWR. Workspaces created since Winter ’25 are enhanced by default, but older configurations are still running in plenty of orgs.
This is not a detail to sort out later. Translation lifecycle, workflows and approvals, collections, and the export format all behave differently depending on which combination you have. Get the answer from your Salesforce admin before you count anything else.
There is a real difference between “our licence renewal went up”, “our editors cannot publish without filing a ticket”, and “we are hitting a documented platform limit”. The first is a negotiation. The second is a workflow problem that a migration may or may not solve. The third is a platform constraint with a deadline attached.
If your answer is the first one, get a renewal quote before you scope a migration. If it is the second, be specific about which step in the publishing process is blocked, because that step is what you will be evaluating WordPress against.
Salesforce CMS gives you three workspace roles: content admin, content manager, and content author. An author can create, edit, and view but cannot publish, which puts it close to WordPress’s Contributor. The set is fixed, and that is the real constraint. If your editorial operation needs a permission Salesforce did not ship, there is nowhere to define one.
Count the people who touch content weekly. If that number is above five and rising, editorial tooling matters more than anything else in this decision.
This is the question that ends the discussion for a lot of organisations. An Experience Cloud site built on the LWR template supports up to 500 routes, or unique URLs, and Salesforce recommends staying below 250 for best performance.
Content volume is not what consumes routes. Salesforce’s own guidance is to serve many items from a single record detail page, which counts as one route, so thousands of articles can sit behind one URL pattern. What uses routes up is structure: campaign landing pages, microsites, sections with a layout of their own. Count those instead. A marketing team shipping forty distinct campaign pages a year reaches the recommended limit long before a publisher shipping five hundred articles does.
Some organisations use Salesforce CMS to serve content that is personalised by CRM records. Others use it because it was already in the contract. These are very different migrations.
If the coupling is real, WordPress can still work, but the architecture has to keep Salesforce as the system of record and pull from it over the API. If the coupling is nominal, the migration is considerably simpler than you expect.
Include the migration itself, licences you will still be paying during the transition, internal time, and training. If the number you have in mind is below $50,000, a full enterprise migration is not going to fit, and you should be looking at a phased approach or a narrower scope.
A contract renewal, a rebrand, a compliance deadline, and “sometime this year” produce very different projects. Deadlines driven by a licence renewal are the most common and the most dangerous, because they encourage cutting the phases that determine whether the migration works.
1.2 Interpreting Your Answers
Strong signals that migrating is right for you. Campaign pages, microsites, and one-off layouts have you near or past the LWR route limit. Your content operation has more than five regular contributors. Your Experience Cloud costs rise with audience growth rather than with output. Your editors work around the CMS rather than in it. You want your public site to be independent of your CRM contract.
Warning patterns that mean you are not ready. Nobody owns the decision. The business outcome is written as “move off Salesforce CMS” rather than as something measurable. The timeline is set by a renewal date and there is no negotiating room. Your integration inventory does not exist yet.
Scenarios where staying put is the right call. If your site is small, gated to logged-in Salesforce users, and tightly personalised against CRM records, Salesforce CMS is doing the job it was designed for and a migration will cost more than it returns. The same is true if your content volume is low and static, or if your organisation has no capacity to own a platform afterwards. We would rather tell you 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 migration case is real.
- Are campaign pages, microsites, and one-off layouts pushing you toward the 250-route recommendation?
- Do more than five people need to publish or edit content in a normal week?
- Does your licence cost scale with something other than the value you get from the CMS?
- Do you need your public web presence to survive a change in CRM vendor?
- 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 the cost of a stalled migration is higher than the cost of not starting.
PART 2: Understanding Your Migration Complexity
Once you have decided to move, the next question is what you are signing up for. Complexity here is driven less by content volume than by how much of your Experience Cloud implementation is custom.
2.1 The Migration Complexity Scale
Salesforce CMS sits in the SaaS and module category, which means there is less custom application code to unpick than with a platform like AEM. That lowers cost. It does not shorten timelines, because the export ceiling and integration rebuild still set the schedule.
Simple Migration (8-14 weeks, $50K-$150K)
Under 5,000 content items, standard content types, a handful of integrations, one language, one editorial team. Your Experience Builder site uses mostly stock components. In practice this describes a marketing site or a resource centre rather than a publishing operation.
Moderate Migration (14-24 weeks, $150K-$350K)
Between 5,000 and 50,000 items, custom content types in use, five to fifteen integrations, multiple brands or languages, several stakeholder groups. You have custom Lightning Web Components in the Experience Builder site that do things stock components cannot. This is where most Salesforce CMS migrations land.
High Complexity Migration (24-40+ weeks, $350K-$750K+)
Over 50,000 items, heavy custom application logic in the experience layer, fifteen or more integrations, gated member portals with non-trivial identity requirements, multi-region governance, or a regulated industry. If your Experience Cloud site is effectively an application rather than a website, you are here.
2.2 What Adds Time and Cost
Five factors move the estimate on a Salesforce CMS migration more than anything else.
Salesforce CMS caps imports at 5,000 items at a time, and if the archive contains more than that, none of them import. The export side inherits the same batching reality. Beyond a few thousand items you are writing scripts against the Connect REST API rather than using the native export, and that is engineering work with its own testing cycle.
Every custom content type in Salesforce CMS needs a matching content detail page in Experience Builder before it renders. Those pages, and any custom Lightning Web Components in them, do not migrate. They get rebuilt as WordPress templates and blocks. Count them early, because this is usually the largest single line in the estimate.
Anything that currently works because content and CRM data share a runtime now has to work over an API. Each integration needs designing, building, and testing separately.
If parts of your site are restricted to authenticated users, you are migrating an authentication model as well as content. This is doable and well-trodden, but it is a workstream, not a task.
Salesforce CMS implementations usually involve a Salesforce admin team, a marketing team, and IT, each with a different view of what the site is for. Every additional group with sign-off authority adds elapsed time regardless of the technical work.
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 content. It does not move the mental model your editors have built up working inside the Digital Experiences app. Those are separate problems, and the second one surfaces three weeks after launch when publishing throughput has halved.
Content model translation is the harder half. Salesforce CMS structures content as workspaces, channels, and content types. WordPress structures it as post types, taxonomies, and fields. The decisions about where things land are editorial decisions dressed up as technical ones, and they need someone who understands how your team actually works.
Budget for structured workshops with your editorial leads before any content moves, field-by-field mapping documentation, and at least two rounds of hands-on training after launch rather than a single handover session.
What it actually costs: $40,000 to $75,000. What it costs to skip: $150,000 to $500,000 in lost organic traffic value.
Experience Cloud URL structures rarely map cleanly onto anything sensible, which makes this harder on a Salesforce CMS migration than on most. Redirect mapping is a reconciliation between every indexed URL you have today, every URL the new site will have, and the gap between them.
The work is a full crawl of the existing 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 actually watching. Treating this as a launch-week task rather than a discovery-phase task costs rankings, and recovery takes six to nine months. Our growth services team runs this as a parallel workstream on enterprise migrations.
What it actually costs: $55,000 to $115,000.
Media libraries are always larger and messier than the inventory suggests. On Salesforce, what governs how fast you can pull them out is your org’s daily API request allocation. Media extraction runs through the Connect REST API and competes with every other integration for the same allocation, so a large library needs scheduling across days and time booked with your Salesforce admin rather than a single unattended pass.
The cost sits in reconciliation rather than transfer. Every asset needs its references rewritten, its metadata preserved where it exists, and its rendition strategy rebuilt. 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 Salesforce CMS”
- 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 the next renewal
Content Readiness
- Full content inventory exists, with counts by content type and by workspace
- Every CMS Collection documented, because the export will not include them
- Content that will not be migrated has been identified and signed off
- Content owners identified for every section
- Editorial workflow documented as it actually runs, not as the policy describes it
- Content counts known per language, including items with partial or no translation
Technical Readiness
- Platform generation confirmed with your Salesforce admin: enhanced or non-enhanced workspaces, Aura or LWR or enhanced LWR site
- Every integration inventoried, with an owner and a contract renewal date
- Custom Lightning Web Components in the Experience Builder site catalogued
- Authentication and identity approach decided
- Hosting decision made
- Data retention and compliance requirements confirmed
Team Readiness
- Internal time commitment estimated honestly and cleared with those people’s managers
- Salesforce admin time specifically budgeted, since they hold the API access
- 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. The discovery and QA phases are the ones compressed under deadline pressure, and they are the two that determine whether the migration is judged a success six months later.
Simple migration: 8-14 weeks. Two to three weeks discovery and content inventory. Two weeks environment and theme setup. Two to three weeks content migration and verification. Two weeks QA and redirect testing. One week launch and stabilisation. One to two weeks training and handover.
Moderate migration: 14-24 weeks. Three to four weeks discovery, including integration mapping and component audit. Three to four weeks environment, theme, and custom block development. Four to six weeks content migration, run at least three times before the real one. Three to four weeks QA, redirect testing, and integration testing. One to two weeks launch. Two to three weeks training and post-launch support.
High complexity migration: 24-40+ weeks. Six to eight weeks discovery, including identity architecture and a full component inventory. Six to eight weeks build. Eight to twelve weeks content migration, often phased by section or brand. Six to eight weeks QA across every integration and access tier. Two to three weeks phased launch. Four or more weeks training across multiple teams.
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 Salesforce-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 your Salesforce setup.
A vendor who quotes a Salesforce CMS migration without asking how many content items you have, how many are in subfolders, and how many CMS Collections you have built is quoting a template. Those three numbers determine whether this is a native-export job or a scripted API job, and the difference is weeks.
If a proposal comes in materially faster than everyone else’s, ask which phase is shorter and why. Compressed timelines get met by cutting QA, redirect mapping, and training, which are exactly the three things you will be judged on afterwards.
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 in a scoping conversation, they are not in the plan. This is the most expensive omission in migration projects and the easiest one to detect early.
3.2 Questions to Ask Every Vendor
Ask all of these.
- How many migrations off Salesforce or Experience Cloud have you completed?
- What was the largest content volume you have moved, and how long did it take?
- 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 handle content that does not map cleanly to the new model?
- What does your QA process cover, and who signs off?
- 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?
- What happens to the team between contract signature and kickoff?
- 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, 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 | Your site is simple | Content volume, integrations, or SEO stakes are material |
A hybrid is under-used and works well: a specialist runs the migration and architecture, your team builds components and owns the platform afterwards. It costs slightly more in the engagement and considerably less over three years. 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. If everything in your brief comes back agreed, nobody has read it properly. Expect to be told that some of what you want is a bad idea, and expect a reason.
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 integration 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 understanding your setup | Asks questions you had not considered |
| 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 in the first call |
| Team | Names not disclosed until signature | Named people, with allocation percentages |
| Risk | No rollback discussion | Rollback plan and a content freeze window |
| Handover | Documentation is a final-phase item | Documentation described as continuous |
| 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 experience pulling content out of Salesforce, WordPress depth at enterprise scale, and a credible answer on integrations.
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 Salesforce CMS 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 Salesforce documents itself, and the objections you will hear internally.
4.1 The Business Case for Migration
Salesforce describes Salesforce CMS as “a hybrid content management system (CMS) where you can easily create and deliver content to any channel or device”. That description is accurate, and it also explains the problem. Salesforce CMS was designed to feed content into Salesforce-connected channels. It was not designed to run a public website at publishing scale, and the platform’s own documented limits make that clear.
The business case for moving is not that WordPress is a better CMS in the abstract. It is that your public web presence and your CRM contract should not be the same decision. Right now they are. If Salesforce pricing changes, if your Experience Cloud licence model shifts, or if you change CRM vendors in five years, your website is part of that negotiation.
Moving the content layer to enterprise WordPress separates those two things while keeping Salesforce as your system of record for customer data. You keep the CRM. You stop letting it own your website.
4.2 Benefits of Migrating from Salesforce CMS 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 route ceiling, no content-type limit | Approval steps that match your process, not the platform’s | Full control of URLs, metadata, and structured data |
| Tooling | Full plugin and package ecosystem, standard PHP and JS stack | Block editor with live preview and reusable patterns | Native SEO tooling, A/B testing, analytics of your choice |
| Control | Own the hosting, the code, and the release pipeline | Capabilities you define rather than three fixed roles | Landing pages without a developer in the loop |
| Talent | Hire from the largest CMS developer pool in the world | Onboard new editors in hours | Agency and freelancer market is deep and competitive |
| Long-term | Portable codebase, no vendor dependency | Workflow tooling that fits how you actually work | Campaign velocity is no longer gated by platform limits |
For Technical Teams
The route ceiling disappears. So does the 100-active-custom-type default, which on WordPress is not a number anyone tracks. You get a codebase you can version-control, deploy through a pipeline, and test properly, on a stack your team can hire for. If you want a decoupled architecture, headless WordPress gives you REST and GraphQL endpoints without the constraints of the LWR template.
For Editorial Teams
WordPress gives you five built-in roles and lets you define capabilities of your own, against three fixed workspace roles in Salesforce CMS. Salesforce does support approval workflows in enhanced workspaces, so the honest comparison is how far you can shape the model rather than whether approvals exist at all. Editors also get live preview, revision history, scheduled publishing, and a block editor that does not require a matching detail page to be built before new content renders.
For Marketing Teams
You control your URL structure, your metadata, your schema markup, and your sitemap directly. Landing pages ship without an admin in the loop. Analytics is whatever you choose rather than whatever integrates, and AI implementation work sits on your own stack rather than waiting for a vendor roadmap.
4.3 Cost Comparison: Salesforce CMS vs WordPress
Direct licence comparison is not possible here, and we would rather say that than print a number we cannot source. Salesforce does not publish Experience Cloud pricing in a form that survives scrutiny, and the figures circulating come from licensing consultancies rather than from Salesforce. What we can compare is the shape of the cost.
| Cost dimension | Salesforce CMS on Experience Cloud | Enterprise WordPress |
|---|---|---|
| What you pay for | Experience Cloud licences, priced on members or logins | Hosting, priced on traffic and resources |
| What makes the bill grow | Audience size | Traffic volume and infrastructure |
| CMS software licence | Included in limited capacity for all orgs; full features require Experience Cloud licences | None, WordPress is open source |
| Vendor lock-in | High, content layer is inside the CRM contract | Low, codebase and content are portable |
| Development cost | Salesforce platform developers, smaller and more expensive pool | WordPress developers, largest CMS talent pool |
| Extension model | AppExchange packages or custom Lightning Web Components | 60,000+ plugins plus custom development |
| Cost of changing vendor | Full rebuild | Move hosts, keep the site |
The line that matters is the second one. A publishing business grows its audience on purpose. Under Experience Cloud licensing, success raises your CMS bill. Under WordPress, success raises your hosting bill, which is a much smaller number and one you can engineer down.
4.4 Why Salesforce CMS Might Be Holding You Back
Four constraints below are documented by Salesforce, not inferred by us.
Salesforce’s own documentation states that an LWR site supports up to 500 routes, or unique URLs, and recommends keeping the number below 250 for best performance. Content volume is not what consumes them, since one record detail page can serve thousands of items. Structure is: every campaign landing page, microsite, and section with its own layout is a route. Marketing-led organisations reach the recommendation years before publishing-led ones do. WordPress has no equivalent limit, and sites in the hundreds of thousands of URLs are routine.
Salesforce CMS caps imports at 5,000 items at a time, and if the archive holds more, none of them import. The same documentation confirms two further problems: content nested in subfolders is flattened to the root on import, and CMS Collection components are excluded from import and export entirely. Your content hierarchy and your curated collections are not in the box.
Experience Cloud licensing is built around members and logins. That model suits a partner portal. It works against a content business, where the goal is more readers, not fewer.
Salesforce’s own documentation lists what LWR templates give up against Aura: no app-level events, no default themes or theme management, no template-level accessibility features such as skip links, several default components and pages missing, restrictions on some Lightning base components, and unsupported properties in the @salesforce/i18n module. You are choosing between an older template and a limited one.
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.
No, and this is the most common misunderstanding about the move. Salesforce stays as your system of record. WordPress reads from it over the Salesforce REST API and writes back through form submissions and event tracking. The connection becomes an integration rather than a shared runtime, which also means it can be tested, versioned, and swapped.
WordPress itself has no licence cost. You will pay for hosting, which you are effectively already paying for inside your Experience Cloud licences. Depending on how many Experience Cloud licences exist purely to serve public content, the net change is often downward. Model it against your actual licence mix before assuming either direction.
WordPress runs a substantial share of the web’s highest-traffic publishing operations. Our own client list includes Rolling Stone, SiriusXM, and Storyful (NewsCorp). At the top end, WordPress VIP provides the infrastructure, and the ceiling is your hosting budget rather than a documented platform limit.
Enterprise WordPress on properly managed hosting carries the same certifications your security team is already asking for. Multidots is SOC 2 Type II compliant, and WordPress VIP maintains enterprise infrastructure certifications. The security 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 moves. WordPress handles role-based content restriction natively, and for enterprise identity you connect to your existing provider over SAML or OIDC. If your members authenticate through Salesforce today, they can continue to, with Salesforce acting as the identity provider.
The pages, yes. The thinking, no. Most Experience Builder implementations contain far fewer genuinely distinct layouts than the page count suggests. The audit usually finds that a large share of templates are used once or twice, and the rebuild targets a smaller block library than teams expect.
Through the API, evaluated either server-side in WordPress or client-side after page load depending on whether the content needs to be indexable. This is well-trodden work. The architectural decision to make early is which personalisation is worth keeping, because teams routinely discover they are maintaining rules that affect very little traffic.
Retraining editors is the cheaper half and typically takes days rather than weeks, because the block editor is closer to tools they already use outside work. Your Salesforce administrators keep doing Salesforce administration, which does not go away. The real cost sits in development capacity, which is why most teams either hire WordPress developers or retain an agency for the first year.
PART 5: How to Migrate from Salesforce CMS 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 piece of content moves. Rushing it is the most reliable way to make the later steps expensive.
1.1 When should we migrate?
The best window is after a licence renewal rather than before one, which is the opposite of what most teams do. Renewal-driven deadlines compress discovery and QA, and those are the phases that determine outcomes. If you can negotiate a short renewal to buy scheduling room, do that.
Avoid launching into your peak trading or publishing period, and avoid the two weeks either side of a major Salesforce release if your integrations touch platform APIs.
1.2 Which CMS should we migrate to?
WordPress is the right answer for most organisations leaving Salesforce CMS, but it is worth being explicit about when it is not. If your primary need is a structured content API feeding several applications and you have a JavaScript team who will own the front end, Sanity may fit better. If your need is a public website with an editorial team behind it, WordPress wins on editorial tooling, talent availability, and cost.
You can also have both. Headless WordPress gives you API-first delivery with WordPress editorial behind it.
1.3 Design strategy: refresh or replicate?
Replicating the existing design makes the migration faster to scope and easier to QA, because every page has an obvious correct answer. Redesigning during migration doubles the number of 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 the migration first on a close replica, then redesign as a separate project 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 Salesforce CMS feature audit and WordPress mapping
Before scoping anything, map the concepts. The table below is the standard mapping and is the right starting point for the workshop with your editorial leads.
| Salesforce CMS concept | What it does | WordPress equivalent |
|---|---|---|
| CMS workspace | Organising and security boundary holding content, languages and contributors | A site, or a subsite in Multisite, plus role scoping |
| CMS channel | Publishing endpoint delivering content to an audience | Front-end theme, or REST/GraphQL endpoint in headless |
| Content type | Determines fields and field behaviour | Custom post type plus registered fields |
| Custom content type | Bespoke type via Content Type Manager, Metadata API or Tooling API | Custom post type, typically with ACF or block bindings |
| Contributor (admin / manager / author) | The three CMS workspace roles | Administrator, Editor, Author, Contributor, plus custom roles |
| CMS collection | Curated or rule-based grouping | Category, tag, or query loop block |
| Content detail page | Experience Builder page required to render each custom type | Single template in the theme hierarchy |
Salesforce CMS ships Document, Image, and News as standard types, with Audio and Video available in enhanced workspaces, and allows 100 active custom content types by default. That 100 is a documented default rather than an architectural ceiling, and Salesforce will raise it on request. Inventory which types you actually use, because on a public publishing site the working set is usually three standard types and a handful of custom ones.
1.5 Third-party integration planning
Every integration needs an owner, a renewal date, and a decision. The categories below cover most Salesforce CMS implementations.
| Category | Salesforce side today | WordPress replacement |
|---|---|---|
| CRM record sync | Native Salesforce objects | Salesforce REST API integration or a connector plugin |
| Marketing automation | Marketing Cloud, Account Engagement | Keep in place, connect over API and forms |
| Identity and gated access | Experience Cloud member licences | WordPress roles plus SSO via SAML or OIDC |
| Commerce | Commerce Cloud | WooCommerce, or keep Commerce Cloud headless |
| Search | Salesforce search | ElasticPress or Algolia |
| Analytics | CRM Analytics | GA4, with server-side event forwarding back into Salesforce |
| Forms | Experience Builder forms | Gravity Forms or Fluent Forms with a Salesforce connector |
Pro tip: the integrations that cause trouble are the ones nobody owns. Run the inventory as an interview exercise rather than a document exercise, and expect to find two or three connections nobody knew were live.
1.6 Enterprise hosting strategy
Hosting is where WordPress performance is won or lost, and the decision constrains everything downstream. 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 most organisations leaving Salesforce CMS, the deciding factors are compliance requirements and whether you need performance optimization support built into the contract.
1.7 Migration team: internal vs. external expertise
You need four things: WordPress engineering, Salesforce API access, editorial decision-making, and project management. The middle two must come from inside your organisation. Nobody external can decide how your content should be structured, and nobody external will have API credentials on day one.
Budget explicit time from your Salesforce administrator. This is the single most commonly underestimated internal cost on these projects, and the migration stalls without them. Media and content extraction both run against the org’s daily API allocation, so scheduling those runs is their call, not the vendor’s. If your WordPress engineering capacity is the gap, embedding vetted WordPress engineers with your existing 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 export of every CMS workspace before anything else happens, and store it outside Salesforce. Export media archives separately from content archives, because that is how the platform structures them and how you will need to reimport if anything goes wrong.
Verify the backup by actually restoring a sample into a sandbox. An unverified backup is a hope, not a plan.
2.2 Content inventory and audit
Count everything, by content type and by workspace. Then flag three categories: content that migrates as-is, content that migrates with changes, and content that does not migrate.
The third category is usually larger than expected and represents real savings. Migration cost scales with volume, and most organisations are carrying several years of content that receives no traffic. Pull the analytics before deciding, and get the decision signed off by content owners rather than made unilaterally. Across our platform migration work, the archive-or-drop decision is the cheapest lever available for bringing a quote down.
Pro tip: run the inventory against your CMS Collections as well, and document each one manually. The export does not include them, so this list is the only record you will have when it comes time to rebuild.
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, not lab tests. Export your backlink profile so you know which URLs carry external authority and must not break.
This baseline is what you will be measured against in month three, and it cannot be reconstructed after cutover.
2.4 Salesforce CMS content structure analysis
Go deeper than the inventory. For each content type, document every field, its type, whether it is required, and what editors actually put in it against what it was designed for. Those two things diverge, and the divergence is where migration scripts break.
Map your workspace and folder hierarchy explicitly, because the export flattens nested subfolders to the root on import. If your structure carries meaning, that meaning has to be reconstructed from a document you write now.
If you run more than one language, document which items have translation variants and which do not. The gaps are what break the transformation, and they are invisible in a straight content count.
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, usually React or Next.js.
Traditional is the right default. It is simpler to run, cheaper to maintain, gives editors live preview without extra engineering, and is fast enough for almost every use case when hosted properly. Choose headless when you have a specific reason: an existing JavaScript front end you are keeping, several front ends consuming one content source, or a front-end team who will own the layer long term.
Pro tip: if the argument for headless is performance, benchmark a properly configured traditional install first. Most perceived performance problems are hosting and caching problems, and headless fixes neither.
3.2 Multisite vs. single site strategy
Multisite suits several sites sharing a codebase, a design system, and an administrative team: regional variants, brand families, campaign microsites. It gives you one place to manage updates and users. This often maps well onto organisations running several CMS workspaces 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, because converting afterwards is a project in itself.
3.3 User roles and workflow configuration
WordPress ships with five roles and lets you define capabilities precisely, which is the main day-to-day upgrade over the three fixed CMS workspace roles. Map your model before building anything.
| 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. Add editorial approval workflows with a plugin such as PublishPress rather than building from scratch.
3.4 Custom Gutenberg blocks and page templates
Custom blocks are where the editorial experience is won or lost. The goal is a small library of well-constrained blocks that make the right layout easy and the wrong layout impossible.
Resist rebuilding every layout variant that exists in Experience Builder today. Audit what your team actually uses. Build the blocks that earn their place, and add more when editors ask.
Pro tip: build block patterns as well as blocks. Patterns let editors assemble approved combinations without a developer, which is where most of the day-to-day speed gain comes from.
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 your Salesforce connector. 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. Audit annually and remove what is unused.
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, and run the whole thing at least three times before the real one.
Phase 1, Export from Salesforce CMS. For workspaces under 5,000 items the native export is viable: content exports as individual JSON files bundled into a .zip, with media in separate archives. Above that, script against the Connect REST API, or use Connect in Apex with the ManagedContent and ManagedContentDelivery classes. Note that the native export cannot be relied on alone at volume, given the 5,000-item all-or-nothing import cap.
Phase 2, Transformation. Map the JSON to your WordPress post types and fields, rebuild the folder hierarchy that the export flattened, resolve internal links, and normalise rich text. This is where the field-level documentation from Step 2.4 earns its cost.
Phase 3, Import into WordPress. Load media first, then content, so asset references resolve. Run in batches with logging on every record. Every run should be idempotent, so a failed batch can be rerun without creating duplicates.
Phase 4, Verification. Compare counts by type against the source. Spot-check rendered output against the live site. Validate that every internal link resolves and every asset reference points somewhere real. Then rebuild your CMS Collections by hand, from the documentation you wrote in Step 2.2, because the export never included them.
4.2 Translated content and language variants
If your workspaces run more than one language, treat translation as its own workstream rather than as a property of each item. Salesforce CMS has a translation lifecycle of its own, enhanced workspaces store translations as language variants of the source content, and the export includes those variant definitions alongside the source.
Decide how the relationships map before transformation starts. Translated posts linked through a multilingual plugin and separate sites in a Multisite network are both defensible, and they produce different content models, different URL structures, and different redirect maps.
Verify counts by language against the source, and include the items with no translation or only partial coverage. Those are the ones that surface after launch as pages rendering in the wrong language or not at all.
4.3 Media and digital asset migration
Pull assets with your org’s API allocation in mind. Media extraction runs through the Connect REST API and competes with every other integration for the same daily request limit, so a large library needs scheduling across days and coordination with your Salesforce admin rather than a single unattended pass.
Preserve filenames where possible, carry alt text across, and regenerate renditions on the WordPress side rather than migrating every existing size. Deduplicate during transformation rather than after import.
4.4 URL mapping and SEO preservation
Build a one-to-one redirect map from the crawl you captured in Step 2.3. No chains, 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.
Migrate metadata, canonical tags, and structured data alongside the content rather than treating them as a post-launch task. Generate and submit a new sitemap on day one, and keep Search Console open for the first 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, not after. 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.5 Pre-launch testing and quality assurance
Test in four passes. Functional, covering every template, form, and integration. Content, comparing a statistically meaningful sample against the source. Performance, against the baseline from Step 2.3. And access, covering every role and every gated content tier, including the authenticated states.
Get editorial sign-off from the people who will actually use the system, doing real tasks, before launch rather than after.
4.6 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 Salesforce environment intact and running for at least thirty days as a rollback path.
Watch error rates, 404s, Core Web Vitals, and organic traffic daily for the first two weeks and weekly for the next three months. Expect a small ranking fluctuation in the first two to four weeks. Expect it to recover. 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.
Establish page-weight budgets by template and enforce them in the build, because performance regressions arrive gradually through content and third-party scripts rather than suddenly through code. Use PageSpeed Insights and GTmetrix for spot checks, and automate the alerting.
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. A short orientation two to three weeks before launch so the interface is familiar. Hands-on sessions in launch week, in the real environment, doing real tasks. And a follow-up two to four weeks after launch, when people have accumulated actual questions. The third session is the one teams cut and the one that changes adoption.
Train by role rather than in one large session. What an author needs and what an editor needs overlap by about half.
5.3 Long-term success strategy
The migration is a project. The platform is not. Name the owner before the project team disperses.
That means a named platform owner, a scheduled update and testing cadence, a quarterly review of plugins and performance, and a route for editors to request changes that does not depend on goodwill. Organisations that skip this end up two years later with an outdated install and nobody who remembers how it was built.
Step 6: Ongoing Maintenance and Monitoring
The platform needs an owner and a cadence. Both should be agreed before the project team moves on to other work.
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 rollback path you have actually tested. Version-control the codebase and deploy through a pipeline rather than through the admin interface.
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 WordPress security 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 configuration and an agency handles code, security and performance, is what most enterprise teams settle on.
Multidots offers WordPress maintenance and support packages covering updates, monitoring, security and performance, along with managed services for teams who want the platform run for them.
Ready to Explore Your Options?
If you are weighing a move from Salesforce CMS 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 Experience Cloud setup, 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 migration. Simple sites with under 5,000 content items and few integrations can complete in 8 to 14 weeks. Sites with heavy custom Lightning Web Components, gated member areas, or more than 50,000 items run 24 to 40 weeks or longer.
The 5,000-item cap applies to Salesforce’s native import and export. Above that volume the migration runs as scripted extraction against the Connect REST API, in batches, with logging and verification on every record. The native export is still useful as a cross-check on a sample, but it is not the primary mechanism at that scale.
They get documented manually before migration and rebuilt in WordPress afterwards, usually as categories, tags, or query loop blocks. Salesforce’s documentation confirms Collections are excluded from import and export, so this is a known manual workstream rather than a surprise. Budget a few days for it and do the documentation during content inventory, not at the end.
Yes, and this is the most common architecture. Salesforce keeps customer data and remains the system of record. WordPress reads from it over the REST API and writes back through form submissions and event tracking. You are separating the content layer from the CRM, not leaving Salesforce.
WordPress handles role-based content restriction natively, and for enterprise identity you connect to your existing provider over SAML or OIDC. If members currently authenticate through Salesforce, Salesforce can remain the identity provider. Plan two to four weeks for this workstream on a moderate migration.
Enterprise WordPress on managed hosting carries the certifications enterprise security reviews ask for. Multidots is SOC 2 Type II compliant and a WordPress VIP Premier Partner. The vulnerabilities WordPress is known for almost always trace to outdated plugins and weak credentials on unmanaged installs, which a managed maintenance process removes.
Phase it if you have distinct sections with separate audiences, more than 50,000 items, or multiple brands. Migrate in one pass if the site is cohesive and under about 20,000 items, since phasing adds coordination overhead and a period where content lives in two systems. Most organisations under 20,000 items are better off with a single cutover.
Your Salesforce administrators keep doing Salesforce work, which does not disappear. For the website itself, most teams either hire one or two WordPress developers or retain an agency for the first year and bring the work in-house afterwards. Editors typically need days rather than weeks to become productive in the block editor.
Core, theme, and plugin updates on a fixed cadence tested on staging first, security patches applied quickly, quarterly plugin and performance reviews, and continuous uptime and security monitoring. Budget for either internal capacity or a maintenance retainer. Teams that leave this unowned accumulate technical debt within about eighteen months.
