Complex CMS Migration Service - Migrate Content

Platform Migrations Aren't Website Design Projects

Anthony Lopez-Vito — Sat, 21 Mar 2026 09:00:00 GMT

Platform migrations fail more often than they should. The cause, rather than being bad work, is almost always because everyone involved missed key considerations they didn't know about. If you're a business or agency moving from a legacy platform to WordPress, Shopify, BigCommerce, or any modern CMS, this article will help you understand where migration projects go wrong and how to avoid a massive headache.

How the Mismatch Happens

A business hires a design agency because...well, that's who builds websites, right? The agency does what they're good at, like design, templates, front-end development. However, a platform migration isn't just a website redesign. There's a whole integration layer underneath. Payment gateways, ERPs, subscription management, accounting feeds, and all that needs to be rebuilt on the new platform. Unless you've hired a Big Agency, all that work sits outside what most shops are set up to deliver. There's no-one on the team who can spot the gaps until the project is already underway, and that's when things get expensive.

Here's how things usually start. The agency scopes what they've been asked to scope. They'll put together a proposal covering design, templates, front-end build, maybe some content migration. It's good work and it's what they do every day. The problem is that any business that's been running for more than a couple of years will have accumulated a stack of connected systems, and those connections are where the real complexity lives.

If you haven't been through one of these projects before, you'll have no idea about how complex things can get.

So you end up with a project where the visible part is moving along nicely but the bit that actually determines success for the business isn't on anybody's plan. Someone dropped the ball. They just didn't realise it because they didn't have the expertise to know better. So the project was framed as a website build from the start when it was far bigger.

What's Actually Underneath

This type of project is my bread and butter, and the pattern is almost always the same regardless of the platform. An e-commerce business moving between platforms will typically have five to ten third-party systems all wired together. Payment gateways (Stripe, PayPal, sometimes both plus the platform's own), subscription management, an ERP for fulfilment, something piping transactions into the accounting software, a marketing automation tool, and usually a couple more that nobody remembered to mention at the start. Large content-heavy sites, like news publishers and membership organisations, have a different but equally complex set of dependencies: editorial workflows, access control, syndication feeds, and integrations with publishing tools or paywall systems.

All of those systems talk to each other through APIs and webhooks, and every one of those connections has to be unpicked, understood, and reassembled on the new platform. This is assuming the new platform even supports them the same way, which isn't always the case. So the finance team can't sign off on going live until the ERP integration works; without it they have no way to record sales. The marketing team can't run their relaunch campaign until they know the date is solid. Customer service needs the new subscription management system working before they can handle enquiries. And all of that has to be coordinated across vendors who live in silos and don't report to each other.

That's plumbing, not page design.

Somebody needs to map all of it before anyone writes a line of code or designs a single page. When I come onto a migration project, the first thing I do is a structured discovery phase. I know from experience that it's vital to document how everything on the old platform translates to the new one. This means how the business actually operates as well as code and third-party services. On one project that meant cataloguing requirements across business processes, integrations, customer workflows, and admin functions. It's not glamorous work, but without it you're building on guesswork.

Where the Gap Opens Up

The agencies on these projects are usually good shops. They have strong portfolios and experienced teams. (Why else would they have been hired in the first place?) But a few weeks in, the client asks for an architecture diagram showing how the integrations connect and the agency's response is some version of "the integrations aren't part of our scope."

And quite honestly, they usually have a point. They were hired to design and build a website. The contract was broad enough that "design and build" could cover anything from a complete platform implementation to what one client described to me as "a set of pretty pictures." The scope gap was there from day one but it took time for anyone to notice.

On another project, the agency lead had to explain to the client that back-end functionality was the platform vendor's responsibility, right at the point when everyone was expecting to see the site actually working. That's a reasonable assumption if you're used to building marketing sites where the platform handles everything out of the box. But none of that mattered half-way into the project. Somebody still needed to deal with the payment token migration, the subscription data, the ERP integration, the accounting feeds, and the go-live sequencing. No-one on the team had the expertise and I was hired too late, just when the migration was about to begin.

So I ended up building the requirements specification, the business process documentation, the test case templates, and the go-live checklist, because if I didn't, nobody would.

There's a similar problem on the technical side. An experienced developer who's strong in one stack can usually pick up a new platform by reading the documentation. Under normal circumstances that's fine but a migration project doesn't give you the luxury of a learning curve. You're already juggling a whole bunch of unknowns. Figuring out an unfamiliar platform on top of all that leads to delays, wrong decisions that have to be unpicked later, and problems that don't surface until you're about to go live.

Business Analysis Is Boring. It's Also the Most Important Part.

Here's something I learned very early on doing site migrations for businesses. There's more at stake than for a hobby site so before anyone writes a line of code or designs a single page, someone needs to sit down and understand how the business actually operates. How do orders flow from the website through to fulfilment and accounting? What happens when a customer modifies a subscription, or requests a return, or changes their payment method? For a content-heavy site, the questions are different but equally important: how does content move from draft to publication, and what integrations feed content to apps, newsletters, or syndication partners? What are the dependencies between systems, and which ones are hard blockers for going live?

This is business analysis, and it's not something most design agencies do because it's not really their job. Their project managers are, quite rightly, geared towards managing creative output, not mapping data flows between an ERP and an accounting package.

There was one migration where the client's finance manager had flagged a hard dependency: the invoice consolidation between the ERP and their accounting software wasn't ready for the new platform. Without it, they couldn't record sales correctly and this would be a complete blocker at go-live. This fell through the gaps and went unnoticed. Again, I was hired too late and only found it because I sat down with the finance team in a discovery session. I asked boring questions about how they actually do their job, then documented everything.

I say boring deliberately. One thing's for sure: migration work is genuinely unglamorous. Agencies take it on because they want the fun creative work. Migrations are about spreadsheets, data mapping, test cases and checklists. It needs a methodical, detail-oriented mindset, rather than creative genius. Of course, the flashy design work is important as that's what customers see, but it's really not the core of a migration project. The core is making sure that everything underneath still works when you flip the switch.

Going Live Is Not "Take the Site Down for a Bit"

So it's time to go live. I've lost count of how many times someone has suggested taking the site down for a period during the switchover. Put up a holding page, swap everything over, bring the new site up.

This works for a brochure site. A mature e-commerce platform with active subscribers, daily transactions, and payment processing is a different beast. Taking the site down means customers can't place orders, subscriptions don't renew, and the business stops generating revenue. For a news or publishing site, downtime means missed deadlines and broken feeds to syndication partners. And if the switchover hits problems (you can't guarantee it won't, no matter how well you plan), "a few hours" can turn into days unless you have a rollback mechanism.

This is why I plan different go-live scenarios for every migration. Usually there's a hard switchover and a phased approach where both platforms run in parallel during the transition. The phased approach works like this: the new site is built and tested on staging. We then do an import of historical and current transactions while the live site keeps running. A final delta migration captures any content or orders that came in. Then a DNS cutover switches traffic to the new site with no interruption. If something goes wrong, you roll back. The business keeps running either way.

Most of the projects I work on end up going with some version of the phased approach, because when you actually sit down with the finance and operations teams and walk through the implications of downtime, nobody wants to take the risk of a hard switchover.

It's not just operations and finance you have to factor in. Marketing will often have planned a campaign around the relaunch, with email sequences, social media announcements, and partner notifications all timed to a specific date. Customer service needs to know what's changing and when, because they're the ones fielding calls from confused subscribers. Even the fulfilment team needs advance notice if order processing is going to look different on the new platform.

A go-live plan that only involves the developers is one that's going to cause huge problems.

Coordinating the Moving Parts

Here's a question that often falls through the gaps: who's responsible for coordinating everyone? What I usually see is the agency assuming the client will do it, and the client assuming the agency will do it. However, a migration for a typical business has the design agency, the platform vendor, one or two third-party integration providers, maybe a specialist for payment token migration, and the client's own team. Everyone's working to different timelines, different priorities, and a different understanding of what's in scope.

Design agency project managers are good at managing creative workflows. They track design approvals, development sprints, and QA cycles. But coordinating a migration is a different discipline since you're not just managing one team's output. You also have to track dependencies across multiple independent vendors, any one of whom can block the whole project.

For example, the ERP provider might need the new platform's API credentials before they can start testing. The payment migration can't happen until the subscription system is configured. The accounting integration needs to be verified before finance will sign off on going live.

Some of this is sequential while some has to run in parallel. If nobody's responsible for tracking how the pieces connect, one delay can stall the whole project. I've seen this happen many times.

For example, there was a time when the agency PM was tracking their design milestones while three integration workstreams were running completely independently with no coordination between them. Everyone was doing their job well, but in silos. Again I was hired well after the migration project started (notice a pattern?) so I needed to centralise everything into a single project management system. That way, when an issue came up in one workstream that would block another, I could flag it before it caused a delay rather than discovering it two weeks later.

And the content migration itself is iterative. People assume you run it once and you're done, but it rarely works like this for a business-critical migration. In practice, it takes multiple iterations to get right. You run a sample, find edge cases, adjust the processes, then run it again. The client's own content editors need to be involved in quality assurance because they know the nuances of how the content should be structured in ways that no external consultant ever will. It's a back-and-forth process that takes patience and attention to detail.

Why It Keeps Happening

I've seen two different agencies attempt the same migration, one after the other. Months of work, tens of thousands spent, and both hit the same wall. The design work was solid but nobody owned the integration layer.

When two good agencies hit the same problem on the same project, that's a structural problem. The good news is it doesn't have to go down this way. Agencies that recognise the gap early and bring in the right expertise for the integration side end up delivering better projects and keeping their clients happy.

Before You Start: What to Check

If you're a business planning a migration, or an agency about to take one on, here are the questions worth asking before anything gets signed.

For business owners

#	Question	Why it matters
1	How many third-party systems are connected to your current platform?	More than two or three and you're looking at a systems integration project, not a website redesign. The risk is in the connections, not the pages.
2	Does your agency contract cover back-end configuration and integrations, or just design and front-end build?	If the contract says "design and build" without specifying integrations, nobody owns the plumbing. Clarify this before work starts.
3	Has anyone mapped your business processes onto the new platform?	How do orders, subscriptions, returns, and payments actually flow through your systems? If nobody has documented this, critical dependencies will surface mid-project.
4	What's the go-live plan? Is anyone suggesting "take the site down for a bit"?	For active e-commerce with subscribers and daily transactions, downtime means lost revenue. You need a cutover plan with a rollback option.
5	Who is coordinating the work across all your vendors?	If that's not clearly assigned to a named person, it's not happening.
6	Have you involved finance, marketing, operations, and customer service in the go-live plan?	Finance needs accounting integrations working. Marketing has campaigns timed to launch. Operations and customer service need to know what's changing. If any of these teams are surprised on go-live day, you have a problem.

For agencies

#	Question	Why it matters
1	How many third-party integrations does the client's current platform have?	More than two or three and the project is bigger than a website build. Scope accordingly.
2	Is back-end configuration and integration work in your scope?	If it isn't, say so clearly in the contract. "Design and build" is ambiguous enough to cause problems later. Specificity protects both sides.
3	Does the client need business continuity during the switchover?	If the client has subscribers, recurring payments, or daily transactions, someone needs to plan a phased cutover. That someone probably isn't your PM.
4	Does your team have direct experience with the target platform's APIs and back-end?	Front-end design skills don't transfer to API-driven integration work. If your developers are strong in WordPress but the target is BigCommerce or Shopify Plus, you probably need a specialist.
5	Do you need a systems integration partner?	Bringing in someone for business analysis, integration work, and vendor coordination lets your team focus on design and build. It protects the client relationship and it protects yours.

What It Looks Like When It Works

When a migration project has the right structure, what the client gets is straightforward: a complete picture of their system before any work begins; a clear scope that everyone has signed off on; a go-live plan that protects revenue; and a single point of coordination across all their vendors. The agency gets to focus on what they're best at without being blamed for integration failures that were never in their scope.

That's what I provide on these projects. The article you've just read is basically my job description and sometimes it requires telling people things they don't want to hear. That once meant recommending the client terminate the project entirely. They kept their existing platform and their active subscribers, and avoided pouring more money into a project that wasn't going to succeed. That recommendation was harder to make than it sounds because I was being paid to oversee the project. Not only are you telling a client who's already spent tens of thousands that the best use of that money was the lesson it taught them, it also meant money out of my pocket. But it was the right call, and they agreed.

Get Someone in the Room on Day One

If there's one thing I'd want someone to take away from this article, it's this: bring in someone to own the whole picture from day one. Right at the start, when the project is being scoped and the contracts are being written.

By the time the agency has been hired and the work is underway, it's too late. The structural gaps are already baked in.

That person doesn't have to be a specialist migration consultant but at the very least, it should be an experienced project manager. Someone who understands multi-vendor coordination and systems integration; someone who's going to map the data flows and business processes before anyone starts designing pages. If you have that person in-house, great. If you don't, that's what I do.

If you're a business looking at a migration with a serious integration layer, have a look at how I handle these projects or the process I follow. If you're an agency and you'd rather bring in someone to handle the business analysis, integration work, and multi-vendor coordination while you focus on the design and build, I work that way too. I'm based in London and work with clients and agencies across the UK and internationally.

Common Questions

Why do platform migration projects go wrong?

It's usually not the agency's fault. Design agencies get hired for the website but the integration layer underneath (payment gateways, ERP connections, subscription management, accounting feeds) needs to be rebuilt too. When the contract doesn't specify who owns that work, the project is already underway by the time the gap becomes visible. The most common pattern is that nobody with systems integration expertise was involved when the project was scoped.

What systems need to be migrated besides the website?

A typical e-commerce platform migration involves five to ten connected third-party systems. Payment gateways (Stripe, PayPal), subscription management, an ERP for fulfilment, accounting integrations, marketing automation tools, and more. Every one of those connections has to be rebuilt and tested on the new platform before you can go live.

Do I still need a design agency for my platform migration?

Probably yes. Design agencies handle the visual output well: wireframes, mockups, page templates, front-end code. But you also need someone who understands the business processes and systems underneath, and can coordinate the integration work across vendors. These are different disciplines, and the best results come from having both covered.

How do I know if my migration is too complex for a design agency alone?

Count how many third-party systems feed data into or out of your current platform. More than two or three and the risk isn't in the page design, it's in the integration layer. If you've got payment gateways, an ERP, subscription management, or accounting feeds connected to your platform, you need someone looking at the whole system.

I'm an agency. How do I avoid this problem on migration projects?

Be upfront about scope from day one. If the project has a serious integration layer, flag it early and bring in someone to handle the business analysis and systems integration side. It protects your client relationship, keeps the project on track, and lets your team focus on the design and build work you're best at.

Why can't we just take the site down during the migration?

For a brochure site, brief downtime might be acceptable. For an active e-commerce platform or a high-traffic content site, taking the site down means lost revenue, missed deadlines, and disrupted customers. Go-live needs a cutover plan that accounts for business continuity, with input from finance, marketing, operations, and customer service, not just the development team.

When should I bring in a migration consultant?

At the very start, when the project is being scoped and contracts are being written. Most migration problems are structural gaps that get baked in early. By the time the agency is hired and work is underway, it's much harder to fix. If you can't hire a specialist, at the very least bring in an experienced project manager who understands multi-vendor coordination and systems integration.

Footnotes

Photo by Kyle Glenn on Unsplash

Migrating Drupal Commerce to WooCommerce: What You Need to Know

Aiden — Thu, 05 Feb 2026 09:00:00 GMT

A typical Drupal Commerce store has 15-20 interconnected database tables: products linked to variations, orders linked to customers, customers linked to addresses and payment tokens. Your online store isn't just content; it's a web of relationships where breaking any single thread corrupts the whole dataset. Here's what's involved in moving from Drupal Commerce to WooCommerce, and why this is one migration you shouldn't try to automate.

Why Automated Tools Fail for E-commerce

Tools like FG Drupal to WordPress, CMS2CMS, and similar migration plugins handle basic content well enough. However, e-commerce data has relationships that these tools can't handle:

Products have variations: sizes, colours, configurations, each with their own pricing, stock levels, and SKUs
Orders reference products, customers, and payments: a single order connects to multiple data entities that must arrive together
Custom fields and attributes: most Drupal Commerce stores have custom product fields that don't map directly to WooCommerce's data model
Payment gateway tokens: stored payment methods and subscription billing need careful handling to maintain PCI compliance

Automated tools treat content as flat data. E-commerce requires preserving the relationships between that data. That requires custom scripting.

Nevertheless, understanding exactly what needs to move is the first step toward getting it right.

What Needs to Migrate

What needs to move depends on your store's configuration. A basic catalogue might only need products and categories, but most active stores have order history, customer accounts, and payment records that all need to come across intact.

Product Data

Product titles, descriptions, and images
Product variations (size, colour, etc.) with individual pricing and stock
SKUs and inventory levels
Custom product attributes and metadata
Product categories and tags
Related/cross-sell product relationships

Order History

Every order in Drupal Commerce is a composite record: line items, statuses (completed, pending, refunded), payment transaction IDs, shipping details with tracking numbers, and any internal notes attached by staff. All of this needs to arrive in WooCommerce with the relationships intact, so a customer's order history page shows the same information it did before.

Customer Data

Customer accounts carry login credentials, billing and shipping addresses, and their full order history. Reviews and ratings need to transfer with the correct author attribution. If your store uses wishlists or saved carts, that data is stored separately from the main commerce tables and needs its own migration path.

The Migration Process for E-commerce

E-commerce migration follows the same iterative approach I use for all complex migrations, with additional steps for the commercial data. The key difference is that Drupal Commerce and WooCommerce store data in fundamentally different ways. Drupal Commerce uses dedicated entity types for products and orders, while WooCommerce consolidates both as custom post types within wp_posts. This means every migration requires custom mapping.

1. Commerce Audit

Before writing any migration code, I need to understand your store's data model. Drupal Commerce is highly customisable, which means every store is different. The audit maps:

Product types and their field configurations
Variation types and pricing rules
Custom checkout flows and payment methods
Tax and shipping configurations
Any custom modules or business logic

2. WooCommerce Architecture

Your Drupal Commerce data model won't map directly to WooCommerce's structure. Drupal Commerce product variations need to become WooCommerce variable products, and custom attributes need sorting into WooCommerce product attributes versus ACF fields. Pricing rules are another consideration: Drupal Commerce's rule-based pricing has no direct WooCommerce equivalent, so the logic often needs rebuilding with a combination of plugins. This planning stage determines which extensions are needed and prevents surprises during scripting.

3. Custom Migration Scripts

I write custom scripts that handle the relationships between products, orders, and customers as a connected dataset. The scripts run iteratively (typically 5-20 test migrations), with each cycle refining the data mapping and handling edge cases.

4. Payment Gateway Transition

This is often the most sensitive part of an e-commerce migration. Considerations include:

Stripe, PayPal, Authorize.net: customer tokens and saved payment methods may transfer, depending on your gateway provider's API
Subscription billing: active subscriptions need careful coordination between the old and new platforms
PCI compliance: payment data handling must comply with PCI-DSS requirements throughout the migration

5. Zero-Downtime Launch

E-commerce sites can't afford downtime. The migration uses a staged approach:

Build and populate the WooCommerce store on a staging server
Run multiple test migrations until data integrity is verified
Execute a final delta migration to capture recent orders
DNS cutover to the new site with no interruption to customers

Common Pitfalls

These are the issues that catch teams off guard in Drupal Commerce to WooCommerce migrations:

Currency and tax configuration. Drupal Commerce and WooCommerce handle tax differently. Make sure your tax rules are properly configured before launch.
Image handling. Product images in Drupal Commerce may use different field structures than WooCommerce expects. Custom mapping is usually required.
URL structure. Product URLs will likely change. A complete 301 redirect map is essential for SEO and for customers who have bookmarked products.
Email templates. Order confirmation, shipping notification, and other transactional emails need to be rebuilt in WooCommerce.
Analytics continuity. Make sure your analytics tracking carries over so you don't lose conversion data.

Timeline and Investment

A Drupal Commerce to WooCommerce migration for a mid-size store (typically 1,000 to 10,000 products) takes around 6-10 weeks and starts at $8,400. The timeline depends on:

Number of product types and variations
Complexity of custom fields and business logic
Volume of order history to migrate
Payment gateway integration requirements
Custom functionality that needs WordPress plugins

The investment protects against the real costs of a failed migration: lost orders, broken customer accounts, and SEO damage that can take months to recover from.

Related reading:

Planning a Drupal Commerce to WooCommerce Migration?

I've migrated Drupal Commerce stores with thousands of products, complete order histories, and customer reviews. Get a free consultation to discuss your store's requirements.

Get a Free Quote

Preserving Your SEO During a Drupal to WordPress Migration

Aiden — Tue, 04 Nov 2025 09:00:00 GMT

SEO is consistently the number one concern for site owners considering a Drupal to WordPress migration, and rightly so. Years of ranking authority, backlinks, and organic traffic are at stake. The good news is that with proper planning, your search rankings can survive the transition intact. The key is understanding exactly where the risks are and addressing each one systematically before launch.

Why Migration Puts Your SEO at Risk

Search engines index your site based on URLs, content structure, and metadata. A platform migration touches all three. When Google crawls your site after launch and finds different URLs, missing pages, or changed metadata, it needs to re-evaluate your content. That re-evaluation doesn't always go in your favour.

The specific risks fall into four categories:

URL changes. Drupal and WordPress generate URLs differently. Without proper redirect mapping, every changed URL becomes a dead link in Google's index.
Missing metadata. Meta titles, descriptions, and Open Graph data stored in Drupal modules don't transfer automatically.
Taxonomy page loss. Drupal's vocabulary listing pages may drive significant traffic. If those pages disappear after migration, that traffic goes with them.
Broken internal links. Links embedded in content that point to old URL structures will return 404 errors.

URL Structure: The Critical Difference

This is where most SEO damage occurs in Drupal to WordPress migrations. The two platforms handle URLs in fundamentally different ways.

How Drupal Handles URLs

Drupal stores URL aliases in the url_alias (Drupal 7) database table, separate from the content itself. Each node can have multiple aliases: /about-us, /about, and /node/28 can all point to the same page. Aliases support forward slashes, allowing deep path structures like /services/migration/drupal-to-wordpress. The character limit is 255.

How WordPress Handles URLs

WordPress stores a single slug in the post_name field within wp_posts. URLs are generated dynamically using rewrite rules based on your permalink settings. Slugs cannot contain forward slashes or quotation marks, and WordPress converts accented characters to their ASCII equivalents. The character limit is 200. Unlike Drupal, WordPress has no mechanism for storing multiple URL variations per page.

What This Means for Your Migration

Any Drupal alias that contains forward slashes, exceeds 200 characters, or includes special characters can't be replicated directly in WordPress. Each of these cases needs a 301 redirect from the old URL to the new one. For sites with hundreds or thousands of URL aliases, this mapping exercise is a significant piece of work, but it's non-negotiable if you want to preserve your rankings.

Building Your Redirect Map

The redirect map is the single most important SEO deliverable in any migration. It's a complete list that pairs every old Drupal URL with its new WordPress equivalent.

Export all Drupal URL aliases: pull the complete URL alias table, including any /node/NID paths that may be indexed
Map each alias to its WordPress URL: based on your chosen permalink structure and any slug changes
Include taxonomy pages: Drupal vocabulary listing pages (/categories/topic-name) need redirects to their WordPress equivalents
Handle user pages and views: if your Drupal site has indexed user profiles or Views-generated pages, these need redirects too
Implement as server-level redirects: .htaccess rules (Apache) or nginx rewrite rules are faster and more reliable than plugin-based redirects

I implement redirects at the server level rather than through WordPress plugins. Server-level redirects execute before WordPress even loads, which means faster response times and no dependency on a plugin that might be deactivated or conflict with an update.

Meta Data Migration

Drupal sites typically store meta titles, descriptions, and Open Graph data through the Metatag module. This data lives in dedicated database tables, separate from node content. WordPress SEO plugins (Yoast, Rank Math, SEOPress) store equivalent data as key-value pairs in the wp_postmeta table.

The migration involves exporting Drupal's metatag records and converting them into the format expected by your chosen WordPress SEO plugin. This isn't something automated migration tools handle, because each SEO plugin uses its own meta key naming convention.

For high-value pages, I recommend a manual review of meta titles and descriptions during migration. A platform change is a good opportunity to tighten up metadata that's been neglected. However, wholesale rewrites should wait until after migration, once you've confirmed your baseline rankings are stable.

Taxonomy Pages and Listing Pages

Drupal's taxonomy system is more flexible than WordPress's default categories and tags. Drupal supports multiple vocabularies with custom fields, and each vocabulary can generate listing pages that rank independently in search results.

Before migration, audit your analytics for taxonomy pages that drive meaningful traffic. These need explicit handling:

Vocabulary-to-taxonomy mapping. Decide which Drupal vocabularies become WordPress categories, tags, or custom taxonomies.
Listing page URLs. Drupal's /taxonomy/term/NID and friendly alias paths need redirects to the equivalent WordPress archive pages.
Custom taxonomy templates. If your Drupal taxonomy pages have custom layouts or additional content, you may need custom WordPress archive templates to replicate them.

What Gets Preserved Automatically

Not everything requires special handling. Several SEO elements transfer naturally because they're embedded in your content:

Heading structure. H1, H2, H3 tags within your content body come across as-is.
Image filenames and alt text. These are stored within the content HTML and transfer with the content.
Internal link structure. Links within content bodies migrate with the text, though the target URLs may need updating to match the new structure.
Content freshness signals. Publication dates can be preserved during migration, maintaining your content's age signals.

Common SEO Pitfalls

These are the issues I see most often in migrations that weren't properly planned:

Forgetting the "Discourage search engines" checkbox. WordPress has a setting under Settings > Reading that tells search engines not to index the site. It's often enabled during development and forgotten at launch. One checkbox can undo all your SEO work.
Changing permalink structure after launch. Pick your WordPress permalink structure before migration and don't change it afterwards. Every change invalidates your redirect map.
Ignoring pagination. If your Drupal site has paginated listing pages that are indexed, those ?page=2 URLs need handling too.
Skipping the XML sitemap. Submit a new sitemap to Google Search Console immediately after launch. This accelerates re-crawling and helps Google discover your new URL structure.
Not monitoring post-launch. The first 4-6 weeks after migration are critical. Monitor Google Search Console for crawl errors, indexing drops, and 404 spikes. Address issues immediately. Delays compound the damage.

When to Invest in SEO Preservation

The level of SEO work depends on your site's organic traffic value. A brochure site with minimal search traffic needs basic redirect mapping and not much more. A content-heavy site with thousands of indexed pages and significant organic traffic justifies a thorough audit, complete redirect map, and post-launch monitoring programme.

I assess this during the initial content audit and provide a recommendation based on your site's actual traffic profile. There's no point over-investing in SEO preservation for pages that don't drive business value, and equally, no point cutting corners on pages that do.

Related reading:

Concerned About Losing Your Search Rankings?

I build SEO preservation into every migration: URL mapping, 301 redirects, metadata transfer, and post-launch monitoring. Get a free consultation to discuss your site's SEO requirements.

Get a Free Quote

Drupal 7 End of Life: Your Migration Options in 2025

Aiden — Wed, 05 Feb 2025 09:00:00 GMT

Drupal 7 officially reached end of life on 5 January 2025, yet hundreds of thousands of websites are still running on the platform. If yours is one of them, you're now operating without security updates from the Drupal community. Here's what that means and what your realistic options are in 2025.

What Drupal 7 End of Life Actually Means

End of life means the Drupal Security Team no longer provides security advisories or patches for Drupal 7. This doesn't mean your site will immediately stop working. It means:

No security patches. New vulnerabilities won't be fixed by the community. Your site becomes increasingly exposed over time.
No module updates. Contributed modules (Views, Webform, Commerce, etc.) are no longer maintained for D7.
Hosting pressure. Many managed hosting providers are phasing out Drupal 7 support or adding surcharges.
Compliance risk. For sites handling personal data, running unsupported software may put you offside with GDPR, PCI-DSS, or industry-specific regulations.

Three Realistic Options in 2025

The right path depends on your organisation's technical resources, budget, and long-term platform needs. However, all three options require action. Staying put is not a strategy.

Option 1: Extended Support (Short-Term Fix)

Several vendors offer paid extended support for Drupal 7, providing security patches beyond the official EOL date. This buys you time but doesn't solve the underlying problem.

Extended support makes sense if you need 6-12 months to plan a proper migration, your site is low-risk (no e-commerce, no sensitive data), and budget constraints prevent moving immediately. It doesn't make sense if you're running Drupal Commerce (increasingly fragile on D7), handling sensitive user data, or you've already been on extended support for a year and the window is closing.

Option 2: Upgrade to Drupal 10/11

Drupal 10 and 11 are the current supported versions. However, upgrading from Drupal 7 is not a simple version bump. It's effectively a complete rebuild. Drupal 7 and Drupal 10 have fundamentally different architectures, templating systems, and content management approaches. This is a critical point that catches many organisations off guard.

The work involved is substantial: a complete theme rebuild (PHPTemplate to Twig), module replacements (many D7 modules have no D10 equivalent), content migration using Drupal's Migrate API, and a custom code rewrite for any bespoke functionality.

When this makes sense:

Your team has strong Drupal expertise and wants to stay on the platform
You have Drupal-specific functionality that's hard to replicate elsewhere
Your organisation has invested heavily in Drupal training and workflows

Option 3: Migrate to WordPress

For many organisations, Drupal 7's end of life is the catalyst to move to WordPress. This is where the "it's a rebuild either way" reality becomes an opportunity. Since a D7-to-D10 upgrade requires complete theme reconstruction, module replacement, and content migration (the same work involved in moving to WordPress), it's worth evaluating whether a different platform better fits your needs going forward.

WordPress powers approximately 43% of all websites globally. That scale translates into practical advantages:

Why organisations choose WordPress:

Lower ongoing costs. Industry comparisons consistently show WordPress annual maintenance costs running lower than equivalent Drupal setups, primarily due to a larger developer talent pool and more affordable hosting options.
Easier content management. WordPress's block editor is more intuitive for non-technical content teams. Your marketing people can publish without developer involvement.
E-commerce ready. WooCommerce is mature and well-supported, with a vast plugin ecosystem.
Faster time to market. WordPress development is typically faster than equivalent Drupal work.

That said, WordPress isn't a drop-in replacement. Several areas need careful handling:

What you need to consider:

Custom content types. Drupal's content type system is more flexible out of the box. WordPress handles this through plugins (ACF, Pods) or custom post types, but it requires planning.
Complex permissions. If your site uses Drupal's granular permission system extensively, this needs careful mapping to WordPress roles and capabilities.
E-commerce data. Migrating from Drupal Commerce to WooCommerce requires specialist handling to preserve products, orders, customer accounts, and reviews.
SEO preservation. URL structures differ between platforms. Proper 301 redirect mapping is essential to protect your search rankings.

What a Professional Migration Looks Like

Regardless of which platform you move to, a complex migration follows a predictable process. For most projects, this typically involves six stages:

Content audit: inventory every content type, field, taxonomy, and relationship
Architecture mapping: design the equivalent structure on the new platform
Custom scripting: write migration scripts tailored to your content structure
Iterative testing: run 5-20 test migrations to catch edge cases
SEO mapping: map old URLs to new, set up 301 redirects
Zero-downtime launch: staged migration with DNS cutover for business-critical sites

This process typically takes 4-12 weeks depending on complexity. Automated migration tools can handle basic content, but the specifics of a real Drupal 7 site (custom content types, complex field relationships, bespoke functionality) all require custom scripting.

The Cost of Waiting

Every month on unsupported Drupal 7 increases your risk. New vulnerabilities won't be patched, and as browsers, PHP versions, and third-party services evolve, compatibility issues will compound.

I've worked on D7 sites where a single contributed module stored data across 15 custom database tables, structures that no automated tool even recognises. The longer those sites run without maintenance, the harder they are to unpick. Meanwhile, managed hosting providers are phasing out Drupal 7 support or adding surcharges for legacy environments.

The migration itself doesn't get cheaper by waiting either. Developer availability tightens as the remaining Drupal 7 talent pool moves on, and the growing technical debt (outdated modules, unpatched core, ageing server dependencies) makes the eventual migration more complex and more expensive.

If you're still on Drupal 7 in 2025, the time to act is now. Whether you choose Drupal 10 or WordPress, a well-planned migration protects your content, your SEO rankings, and your business.

Related reading:

Need Help With Your Drupal 7 Migration?

I specialise in complex Drupal to WordPress migrations, including e-commerce, custom content types, and business-critical sites that need zero-downtime launches. Get a free, no-obligation consultation to discuss your options.

Get a Free Quote

Drupal 7 End of Life: Why WordPress is the Best Migration Option for Lower Maintenance Sites

Aiden — Tue, 17 Dec 2024 14:25:15 GMT

Drupal 7 will reach end-of-life in January 2025. Learn why migrating to WordPress makes sense for small businesses, agencies, and anyone looking for an affordable, flexible CMS solution.

Drupal 7 is reaching the end-of-life (EOL) on 5th January 2025. This means official support will stop, leaving around 180,000 websites vulnerable to security risks, compatibility issues, and rising maintenance costs. If your site is still running on Drupal 7, it's time to make a decision.

For many, upgrading to the latest version might seem like the logical next step. Currently Drupal 11, which was released in July 2024, the move from Drupal 7 isn't a simple update but rather, it will require a complete rebuild. For smaller teams, freelancers, or businesses, this can mean significant time, money, and stress.

Drupal is well-suited for large, complex websites that require advanced functionality. This includes enterprise-level businesses, government portals, higher education institutions, and NGOs. That said, Drupal's steep learning curve and resource-intensive nature make it less suitable for small businesses or individuals who need a simple, low-maintenance website.

This is where WordPress comes in. With its lower costs, ease of use, and massive community support, WordPress has become the go-to CMS for businesses who need a better balance of simplicity and functionality. Whether you're running a small agency, freelancing, or managing your own business site, WordPress offers a practical, future-proof solution.

Final Deadline Announced After Multiple Extensions

The Drupal Association has announced several end-of-life dates for Drupal 7 over the years:

The latest and final EOL date for Drupal 7 is January 5, 2025, was made to give organizations more time to migrate their websites to newer versions of Drupal or other platforms.

What Happens If You Stay on Drupal 7?

It should go without saying that sticking with Drupal 7 after its End of Life isn't a viable long-term option because it will no longer receive official updates, security patches, or technical support.

This leaves site owners and maintainers with a range of headaches:

Security Risks: Without updates or security patches, your site becomes a prime target for hackers.
Compatibility Issues: Over time, browsers, APIs, and third-party tools will evolve, leaving your site unable to keep up. Things will start breaking—slowly at first, then all at once.
Rising Costs: Developers who still work with Drupal 7 are becoming harder to find, and their rates reflect that scarcity. Maintaining an outdated platform will only get more expensive.

If you're still on Drupal 7, the clock is ticking. It's time to start planning your next move.

Why Choose WordPress Over Upgrading Drupal?

WordPress has grown into the most widely used CMS in the world, powering around 43% of websites and 229,000 of the top 1 million sites by traffic. Popularity isn't the only reason to choose WordPress though.

For starters, it's easier to use because WordPress's intuitive interface means you don't need a developer for every little update. Your team can manage content, make changes, and even build pages without technical expertise.

It's also more affordable. While both Drupal and WordPress are open-source, WordPress generally offers a better return on investment with lower build and maintenance costs. Drupal's complexity leads to higher development expenses and more costly, time-intensive updates.

And then there's WordPress' massive global user base, which means there's no shortage of resources, tutorials, and developers. If you need help, it's easy to find.

Is it Worth Upgrading Drupal?

Upgrading to Drupal 11 is an option, but it's not a simple one. Architecturally, the jump from Drupal 7 to 11 is massive. The two versions are so different that you're essentially rebuilding your site from scratch.

For some organisations, that's fine. Nevertheless, if you're running a complex site with custom features that rely on Drupal's architecture, it might even be necessary. In fact, Drupal is often overkill for smaller businesses or agencies.

Futhermore, Drupal has gravitated towards enterprise-level projects over the past few years so if you don't need that complexity, WordPress is a more practical, cost-effective choice.

Real-World Success Stories

During a recent WP Engine webinar, Emily Averill, Digital Marketing Director at Daniels Health, shared their reasons for migrating from Drupal 7 to WordPress:

"The [Drupal] website wasn't a place that our team could work confidently or with pace or agility. It was a friction point, and so we wanted a platform that could grow with us as an organization...Yes, it was going to be a hard migration. But in order to achieve the outcome, the future state we really wanted, it was going to be worth it...Replatforming for us in reality has been easier than migrating from Drupal 7 to 10."

This is a common theme among businesses that have made the switch. WordPress's user-friendly interface and flexibility make it a better fit for teams that need to move quickly and efficiently.

The Migration Process

Migrating a site can feel overwhelming, especially if you've been on the same platform for years. Here's how I handle the process.

The Process:

Project Discovery: I analyse your requirements and site's content, custom features, user roles, and integrations.
Migration Planning: I determine what needs to be migrated, what can be replaced with WordPress plugins, and what might need to be rebuilt.
Custom Solutions: If WordPress doesn't have an out-of-the-box solution for something, I'll build it.
Optimisation: Once the migration is complete, I optimise your new site for performance, security, and scalability.
Training: I provide training so your team knows how to manage the new site.

By the time I'm finished, you'll have a site that's ready for the future.

Why WordPress is the Smarter Choice Today

Continuing to build on outdated Drupal software not only increases complexity but also creates significant technology debt, making future development more costly and inefficient.

As Scott Jones from Illustrate Digital explains in the WP Engine webinar, continuing on Drupal often means that new features and functionality are being developed on old underlying software and frameworks, which can hinder growth and innovation.

In contrast, WordPress offers a modern, intuitive interface that empowers marketing teams to take control of content publishing without relying heavily on developers. Webinar panelist PeterJohn from Useful Group highlights that WordPress is more marketer focused, while also evolving its developer tools to rival or surpass Drupal.

By migrating to WordPress, businesses can reduce costs, streamline workflows, and future-proof their digital presence.

Let's Talk

If you're still running Drupal 7, it's time to make a move. Whether you're ready to migrate or just exploring your options, I'm here to help.

Drupal to WordPress migration service

Any Drupal version · All content · Custom content types · SEO · Plugins

Get in touch today for a free quote. Let's figure out the best path forward for your site—and your business.

Drupal 7 End of Life Frequently Asked Questions

These FAQs are drawn from the real-world experience of the WP Engine webinar panelists.

Why are organizations moving away from Drupal?

Several factors contribute to the shift away from Drupal, particularly Drupal 7, which reaches its end of life in January 2025. These include:

End of life for older versions: This necessitates full rebuilds, leading to significant effort and cost.
Technological debt: Building new features on outdated software creates challenges and limits agility.
Shifting decision-making: Marketing teams, who are most impacted by the CMS choice, now have a greater say, leading to a preference for more user-friendly platforms.
Rise of alternative platforms: Modern platforms like Next.js and WordPress offer attractive features and benefits.

What are the advantages of WordPress for marketing teams?

WordPress offers several benefits that make it particularly appealing to marketers:

Intuitive content management: WordPress's user-friendly interface and familiar structure make it easy to learn and use, even for junior team members.
Ease of content publishing: The block-based editor and intuitive design streamline content creation and editing.
Extensive plugin ecosystem: A vast library of plugins provides seamless integration with marketing tools and services, expanding functionality without custom development.
Flexibility and agility: WordPress allows for quick site deployment and iterative improvements, enabling rapid responses to market changes and opportunities.

How does WordPress benefit technical teams?

Beyond its marketing advantages, WordPress also offers benefits for developers:

Gentle learning curve: The platform is relatively easy to learn, reducing the training burden and enabling faster onboarding of new team members.
Strong community support: A large and active community provides ample resources, documentation, and support for troubleshooting and development.
Wide choice and flexibility: WordPress offers a vast selection of themes, plugins, and development tools, allowing for customized solutions and integrations.
Scalability and adaptability: WordPress can scale to accommodate large and complex websites, and its open-source nature allows for customization to meet specific needs.

What happens to my Drupal 7 website after January 2025?

No more updates: Drupal will cease releasing feature developments and security updates for Drupal 7.
Increased security risks: Without ongoing security patches, your website becomes vulnerable to exploits and attacks.
Limited functionality: You will no longer receive updates for modules and themes, potentially impacting website performance and functionality.

How do I address security concerns about WordPress?

Present data and evidence: Share data on WordPress's adoption rate, security infrastructure, and the expertise of partners like WP Engine and specialised agencies.
Engage IT and security teams: Involve them early in the decision-making process, address their concerns directly, and demonstrate how WordPress meets security standards.
Emphasise hosting and infrastructure: Highlight the role of managed WordPress hosting providers like WP Engine in ensuring security, performance, and reliability.

Is it easier to upgrade to the latest Drupal version or migrate to WordPress?

Upgrading to the latest Drupal version might seem simpler, but it can involve substantial effort due to significant code changes and underlying technology changes.
Migration complexity can be high regardless of whether you upgrade within Drupal or migrate to a different platform, especially with large amounts of content.
WordPress's iterative approach offers more frequent and gradual updates, minimising disruption and making it easier to maintain the site over time.

How is content migrated from Drupal to WordPress?

Content evaluation: Assess the existing content, identify what needs to be migrated, and determine if any cleansing or restructuring is required.
Data export: Export content from Drupal using tools like the Views Export module to create structured data files.
Data import: Utilise WordPress import plugins like WP All Import to bring the content into the new platform, with potential customisation for complex data structures.
Testing and validation: Thoroughly test the migrated content to ensure accuracy, functionality, and proper display on the new WordPress site.

What is a typical timeframe for a Drupal to WordPress migration project?

Content migration: Typically takes around 4 weeks, depending on the volume and complexity of the content.
Full website rebuild: Including design, development, and content migration, can range from 5 to 12 months, depending on the scope and complexity of the project.
Global multi-site projects: As in Emily's case, can take up to 48 weeks, encompassing research and development, design, build, testing, and launch phases.

Footnotes

Featured image photo by Rafael Garcin.

The Benefits of migrating from Drupal to WordPress: Key Insights from WP Engine's Latest Webinar

Aiden — Fri, 22 Nov 2024 15:28:15 GMT

Last August 2023, the Drupal Association announced the date of 5th January 2025 as Drupal 7's offical End of Life. This means that while individual developers can continue to maintain their sites and modules, Drupal 7 core will no longer receive official support, updates, or maintenance. Site owners, developers and agencies have been assessing their options: do they upgrade to Drupal 8 or find an alternative platform? Neither decision is easy.

WP Engine recently hosted a webinar offering insights from a panel of experts, revealing why enterprises are choosing WordPress over Drupal in 2024. In this post, Aiden summarises the key points and statistics from the session.

Watch the Webinar

Speakers

Scott Jones, CEO, Illustrate Digital
Chandan Sharma, Web Development Manager, Bluetext
PeterJohn Hunt, CTO at Useful Group
Emily Averill, Digital Marketing Director at Daniels Health

The Current CMS Landscape

Drupal's Declining Position

According to Scott Jones's presentation, Drupal has experienced a notable decline in usage since 2021, particularly among enterprise brands. A critical factor driving immediate decisions is Drupal 7's impending end-of-life in January 2025, after which security patches and updates will cease.

Webinar slide deck: Drupal's overall decline

WordPress's Market Dominance

The webinar highlighted WordPress's commanding presence among the top 1 million sites by traffic. As PeterJohn noted during the session, "WordPress has done well to really stabilize the amount of changes, and how often those changes are going on... in a way that serves enterprise especially."

Webinar slide deck: Illustrate Digital's recommendation

Key Migration Drivers

Ease of Use and Training

Emily Averill's experience at Daniels Health provided a compelling real-world example. She shared that transitioning to WordPress proved more straightforward than upgrading within the Drupal ecosystem, emphasizing improved team productivity post-migration.

Cost Considerations

The panel discussed several financial advantages:

Lower implementation costs compared to Drupal upgrades
Reduced ongoing maintenance expenses
Better marketing team ROI through improved efficiency

Drupal vs WordPress: Total Cost of Ownership

Cost	Drupal	WordPress
License fee	$0 / year £0 / year	$0 £0
Example build cost	$165,000 - $250,000 £120,000 - £180,000	$100,000 - $200,000 £80,000 - £150,000
Example maintenance cost	$15,000 / year £11,000 / year	$11,500 / year £8,400 / year
Example hosting cost	$5,000 - $10,000 / month £3,500 - £7,000 / month	$5,000 - $7,000 / month £3,500 - £5,000 / month
Example ongoing development cost	$1,500 - $2,000+ / month £1,000 - £1,500+ / month	$1,500 - $2,000+ / month £1,000 - £1,500+ / month

Technical Flexibility

Chandan from Bluetext shared a success story of migrating a complex Drupal site to WordPress within tight deadlines, demonstrating the platform's efficiency and adaptability.

Practical Migration Considerations

Pre-Migration Planning

Based on the panelists' recommendations:

Conduct thorough site mapping and content architecture evaluation
Identify critical content for migration
Plan for both automated and manual content transfer

Stakeholder Engagement

The webinar emphasized involving:

Marketing teams for content strategy
IT and cybersecurity teams for security protocols
Development teams for technical implementation
Content editors for training and workflow adaptation

Security and Maintenance

Security Protocols

Key takeaways from the discussion:

Early involvement of cybersecurity teams is crucial
Address legacy security concerns during migration
Implement robust security measures from day one

Ongoing Maintenance

The panel highlighted WordPress's advantages:

More streamlined update processes
Focus on quality over quantity with plugins
Stronger community support for troubleshooting

Real-World Success Story

The webinar featured Daniels Health's migration journey, where Emily Averill noted: "The culmination of all of that is that it's far easier to do that in the WordPress platform... than it is on the Drupal platform, as was our experience back in the day."

Conclusion

Scott Jones's statement perfectly encapsulates the webinar's message: "WordPress is still the best CMS. It's still trending up, and until it gets really credible competition with something else that's got really high usage, he'll continue to recommend it for both small businesses and enterprises alike."

Considering a migration? Get in touch for a free assessment. For additional insights, check out the Drupal to WordPress Migration Guide.

Appendix: Key Statistics from the Webinar

1. The Current CMS Landscape

Drupal's Market Position

Approximately 180,000 websites still running on Drupal 7
Drupal 10 has only 75,000 installations currently
Drupal 11 (released in August) has approximately 1,300 installations
Showing significant decline since 2013, with accelerated decline since 2021

WordPress's Dominance

Powers 229,000 of the top 1 million sites by traffic
Controls approximately 41% of all content-managed websites
Powers 34 million websites across the entire internet

2. Critical Timeline Considerations

Version Support Deadlines

Drupal 7 end-of-life: January 2025
Drupal 10's end-of-life: Already set for 2026
Versions 8 and 9 still haven't been as popular as Version 7

Migration Timeframes

Average content migration timeline: 4 weeks
Full project timeline example (Daniels Health): 48 weeks including R&D process
Complete website rebuilds with new design: 5-12 months

3. Technical Migration Considerations

Platform Differences

Drupal 7 to Drupal 10 migration requires complete theme rebuild
Significant architectural changes between versions (PHP files to Twig templates)
Custom modules need complete rewriting for newer Drupal versions

WordPress Migration Benefits

More streamlined update processes
Stronger community support for troubleshooting
More intuitive content management interface

4. Security and Maintenance

End-of-Life Impact

Sites won't automatically go down after end-of-life
Security updates and patches will cease
Sites become increasingly vulnerable to security risks

Footnotes

Aiden is an AI agent and just like a human, it can make mistakes. This summary is posted for convenience but you can verify the statistics by watching the video in full.
Thumbnail photo from the WP Engine Drupal to WordPress Webinar, 12th November 2024.
WP Engine's slide deck for the webinar can be found at From Drupal to WordPress: The Benefits of Migrating Your CMS.

How To Set Up Drupal 7 Docker Containers for Migration Projects

Anthony Lopez-Vito — Mon, 09 Sep 2024 13:25:15 GMT

Docker is a valuable tool for Drupal 7 end of life migrations. In this post, I'll give a step-by-step guide to setting up a Drupal 7 container for your migration project. Instructions for the migration itself are out of scope for this article but you will have a running Drupal installation that can be used with a migration tool of your choice.

1. Introduction

After several deadline extensions, the Drupal Association has confirmed that Drupal 7 will officially reach end of life (EOL) on 5 January 2025. For site owners, agencies, and freelancers who've postponed making a decision, the time has come to make a choice. Do you upgrade to a newer version of Drupal, or migrate to an entirely different platform? Neither option is straightforward.

I sympathise with the "if it ain't broken, don't fix it" approach to most things, especially for something like a business-critical website. It's hard to justify disrupting a system that's running without any apparent problems. However, a Drupal 7 site migration is now unavoidable. Drupal Core will no longer be supported after EOL and hiring developers to keep it maintained, while a possibility, will not be feasible in the long term.

2. Upgrade Drupal 7 or Migrate?

It's important to understand that moving from Drupal 7 to a newer version of Drupal isn't a straightforward upgrade. Most Drupal developers already know this but it's worth pointing out early on. Unlike typical software updates, upgrading to Drupal 8 or higher involves a complete rebuild of the site.

In other words, whether you plan to upgrade or migrate to a different content management platform like WordPress, the work involved is fundamentally going to be a migration project. For this reason, throughout this article, I'll use the terms 'migration' and 'upgrade' interchangeably. Both scenarios involve similar planning, testing, and execution requirements, as well as the need for a temporary development environment.

3. Hassles with Setting up the Migration Environment

Unfortunately, site migrations are notoriously intricate, requiring careful planning and execution. Even getting set up for a migration can feel like an uphill battle. In 2012, when we first started specialising in Drupal to WordPress migrations, local web development involved making sure the whole application stack was configured properly for each project. This meant setting up a virtual host on the development machine web server, as well as getting the database and PHP configurations right. Virtualisation tools like VirtualBox existed, but they often performed poorly, freezing frequently and proving unreliable for sustained work.

The release of Docker in 2013 introduced a better way to manage development environments. As an open-source containerisation platform, it solved many of the problems developers faced when setting up for new migration projects. By isolating environments within lightweight containers, Docker streamlined workflows and eliminated many of the common compatibility headaches. By around 2018, it had become a standard tool for development teams worldwide, replacing clunky and expensive solutions like virtual machines.

In this guide, we'll outline how to set up a Docker container tailored for Drupal 7 migrations. We'll also explain how Docker simplifies the migration process while providing the flexibility required for more complex scenarios.

4. An Introduction to Docker

I'll start off with some basics for readers who aren't familiar with Docker. Feel free to skip to the setup steps if you don't need the introduction.

What is Docker?

Here's a quick overview if you're unfamiliar with the technology. Docker is a containerisation platform that lets you bundle applications and their dependencies into isolated units called containers. You can think of a container as a self-contained environment where everything your project needs, such as applications, libraries, and other dependencies, are bundled together. This approach ensures that the software runs consistently, regardless of the underlying system.

Unlike the old virtual machines, which emulate an entire operating system, Docker containers share the host system's kernel. This makes them lightweight, fast, and resource-efficient. Portability is central to Docker's appeal. A container built on a developer's laptop will work the same way on a production server. Combined with tools like Docker Compose, which orchestrates multi-container setups, you can recreate entire environments with just a few commands.

Why Use Docker for Migrations

Setting up a migration project used to require a huge amount of effort, especially for a Drupal 7 to WordPress conversion. It was a nightmare juggling multiple client projects on a single development machine. You would need to set up Apache virtual hosts for the new project sites and sometimes tweak system-wide PHP versions or database settings. If there was a risk of introducing a breaking change for another project, I would have to dig out and set up a spare physical machine.

Docker helps streamline the project setup tasks by offering isolated containers for each client, reducing the time spent building the environment and troubleshooting compatibility issues. For example, a Drupal 7 site may need PHP 5.6, while a new WordPress installation might require PHP 8. With Docker, you can run both versions in separate containers, avoiding annoying conflicts.

Docker volumes ensure data persistence for databases and installation files, even if a container is removed. Starting over from a botched migration simply means rebuilding the container from a pristine state—a process that usually takes minutes.

Key Advantages and Limitations of Docker

Docker is lightweight compared to traditional virtual machines. It shares the system kernel, allowing you to run multiple containers without overloading your system. This makes it particularly useful for testing different configurations or managing multiple projects.

However, it's important to note some limitations. Building Docker images for the first time can be time-consuming, and unused containers or images can quickly consume disk space if not managed regularly. Also, keeping a clean and efficient environment requires periodic maintenance. This can be annoying when you're knee-deep in a complex migration and you find your development machine running out of disk space.

Docker is not a complete solution for all problems, but thankfully, known issues like security concerns, networking challenges, and resource management apply to production sites rather than temporary migration environments.

Essential Docker Concepts

I'll go over some important basics before delving into the steps for setting up Docker Containers for Drupal 7 Migration Projects. You might get a little lost without an understanding of these concepts so be sure to at least skim through them if you're new to Docker. You can find information over on the dockerdocs.

Containers: Containers are lightweight, portable units that package your application and its dependencies. They run isolated from each other and the host system, ensuring consistency across development, staging, and production environments.
Images: A Docker image is a pre-configured snapshot that defines what is inside a container. Images include your application, libraries, runtime, and any dependencies.
Dockerfile: A Dockerfile is a text file with instructions for creating a Docker image. It defines the base image, environment variables, software installations, and configuration commands.
Volumes: Volumes are used to persist data generated by a container. They're essential for making sure changes to the Drupal database or files aren't lost when the container stops or is removed.
Networks: Docker's networking features allow containers to communicate with each other or with external services. For example, you could use the network to send data from Drupal container to a WordPress container, or a container that holds your migration utilities.
Docker Compose: Docker Compose is a tool that allows you to define and run multi-container Docker applications using a docker-compose.yml file. It simplifies the management of environments with multiple interconnected services (e.g., a Drupal site with a PHP container, a database container, and a reverse proxy).
Registry and Docker Hub: Docker Hub is a public registry where developers can find and share Docker images. Knowing how to pull official images from trusted sources and push your custom images to private or public registries is an important skill.
Commands and CLI Basics: Familiarity with Docker CLI commands like docker build, docker ps, and docker compose up -d --build will allow you to manage and troubleshoot containers effectively. See the command-line interfaces documentation for more about the commands.

5. How to Set Up Docker Containers for Drupal 7 Migrations

By now you should have a good understanding of what Docker is, how it can help with a migration project, and some basic concepts. Let's get on with actually setting it up. Here we'll create a container to install Drupal 7.103, released on 4 December 2024, with a full stack including web server, database and Drush.

1. Install Docker

First, ensure Docker is installed on your system. You can follow Docker's official installation guide for your operating system. I find the most convenient method is to install Docker Desktop which includes all the Docker tools and is available for Linux, Mac and Windows.

2. Create Your Project Structure

Create a folder structure for your migration project. Here's a variation of the project structure we use.

project/
├── .env                    # Secrets and environment variables
├── backups                 # Local backups directory
├── docker-compose.yml
├── docker/
│   ├── drupal-[version]/
│   │   └── Dockerfile
│   └── phpmyadmin/
│       └── Dockerfile
├── logs                    # Log files
├── src/                    # Your local Drupal installation files
└── utils/                  # Your migration utilities

File and Database Persistence

File Changes: Drupal core/theme/module changes will persist on host through a mapping to the ./src directory.
Database Changes: the database will be stored in a named volume managed by Docker. The data will persist across container restarts/rebuilds unless the volume is manually deleted.

3. Download the Drupal Installation Files

We will use Drupal 7.103 for our container. (Note: This is the newest version, released on 4 December 2024, as of the last update for this article.) Download it from the Drupal website and extract the files into your ./src directory.

The container will create a bind mount to map the ./src directory on the host machine to /var/www/html inside the container. This means that any changes made to the files in the container at /var/www/html will be reflected in the ./src directory on the host machine, and vice versa.

4. Create Your `.env` File

The .env file is a text file used by Docker Compose to define environment variables. These variables can be referenced in the docker-compose.yml file to make your configurations more flexible and easier to manage. It's a good way of preventing sensitive information like passwords from being included in source control.

It will look something like this:

DRUPAL_DB_HOST=db
DRUPAL_DB_USER=dbuser
DRUPAL_DB_PASSWORD=dbpass
DRUPAL_DB_NAME=drupal_db

MYSQL_ROOT_PASSWORD=root

Ensure you adjust it to use your own variables.

4. Create Your Drupal Dockerfile

The Dockerfile sets out the instructions for creating a Docker image, defining the base image, environment variables, software installations, and configuration commands.

An image for Drupal 7.103 with Apache, Drush and PHP Composer might look like this:

FROM drupal:7.103-apache

# Install required PHP extensions and tools
RUN apt-get update && apt-get install -y \
    vim \
    git \
    unzip \
    libicu-dev \
    libzip-dev \
    libxml2-dev \
    libonig-dev \
    zlib1g-dev \
    default-mysql-client \
    && docker-php-ext-install pdo pdo_mysql zip intl \
    && rm -rf /var/lib/apt/lists/*

# Configure PHP
RUN echo "memory_limit = 256M" > /usr/local/etc/php/conf.d/memory-limit.ini \
    && echo "upload_max_filesize = 64M" > /usr/local/etc/php/conf.d/upload-limit.ini \
    && echo "post_max_size = 64M" >> /usr/local/etc/php/conf.d/upload-limit.ini

# Install PHP extensions needed by Drupal
RUN docker-php-ext-install pdo pdo_mysql zip intl

# Enable Apache mods commonly needed by Drupal
RUN a2enmod rewrite

# Install Composer (from the Composer official image)
COPY --from=composer:2 /usr/bin/composer /usr/local/bin/composer

# Install Drush globally via Composer
RUN composer global require drush/drush:8.*

# Ensure Drush is on PATH
ENV PATH="/root/.composer/vendor/bin:${PATH}"

# Set the container working directory
WORKDIR /var/www/html

# Ensure the Apache user (www-data) owns the web root
RUN chown -R www-data:www-data /var/www/html

This grabs the offical Docker Hub repository image for Drupal 7.103 with the Apache web server. You'll notice the Drupal image doesn't include any specifications for a database. This will be handled by the docker-compose.yml file later.

If you followed my project structure above, place this Dockerfile in a drupal-7.103 folder inside the docker subdirectory.

Adjust the Dockerfile for your own needs but here are some notes to avoid headaches:

default-mysql-client: If you're familiar with installing MySQL on a Linux system, you might be tempted to run apt-get for mysql-client. Don't do this. The Docker repository for drupal:7.103-apache is based on Debian Bookworm (Debian 12). Debian has stopped packaging mysql-client as of Debian 10 so you will encounter errors. Make sure you use the default-mysql-client metapackage instead. This will install the MySQL compatible mariadb-client.
composer:2: Although Drupal 7 does not have native Composer support, we are using it to install Drush.
drush:8: Install Drush 8, which is the latest compatible version Drupal 7 websites. A later version will install but you will encounter errors running some Drush commands.

5. Create a phpMyAdmin Dockerfile (optional)

This step is optional but it's useful to install phpMyAdmin so that you can do some basic database tasks. A phpMyAdmin Dockerfile that pulls the latest version of phpMyAdmin from the official Docker Hub repository would look like this:

FROM phpmyadmin:latest

# Add ServerName configuration
RUN echo "ServerName localhost" >> /etc/apache2/apache2.conf

Place this Dockerfile in a phpmyadmin folder inside the docker subdirectory.

6. Create Your `docker-compose.yml` File

Docker Compose will let you define and run all the necessary applications using a docker-compose.yml file. The example below defines services for Drupal, MySQL and phpMyAdmin, and should be saved in the root of your project folder. Please read the Compose file reference for a detailed explanation of each section in order to customise it for your needs.

services:
    drupal:
        build:
            context: .
            dockerfile: ./docker/drupal-7.103/Dockerfile
        ports:
            - "8088:80"
        volumes:
            # Ensure you copy your Drupal site here to avoid permission issues
            # If you are starting with a fresh Drupal installation, download
            # the correct Drupal version and extract it here.
            # https://www.drupal.org/project/drupal/releases/7.103
            - ./src:/var/www/html:cached
        depends_on:
            db:
                condition: service_healthy
        env_file:
            .env
        environment:
            DRUPAL_DB_HOST: ${DRUPAL_DB_HOST}
            DRUPAL_DB_USER: ${DRUPAL_DB_USER}
            DRUPAL_DB_PASSWORD: ${DRUPAL_DB_PASSWORD}
            DRUPAL_DB_NAME: ${DRUPAL_DB_NAME}
            PHP_FPM_USER: www-data
            PHP_FPM_GROUP: www-data

    db:
        image: mysql:5.7
        env_file:
            .env
        environment:
            MYSQL_DATABASE: ${DRUPAL_DB_NAME}
            MYSQL_USER: ${DRUPAL_DB_USER}
            MYSQL_PASSWORD: ${DRUPAL_DB_PASSWORD}
            MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
        volumes:
            - db_data:/var/lib/mysql
        ports:
            - "3307:3306"
        healthcheck:
            test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "drupal", "-pdrupal_pass"]
            interval: 10s
            timeout: 5s
            retries: 5

    phpmyadmin:
        build:
            context: .
            dockerfile: ./docker/phpmyadmin/Dockerfile
        ports:
            - "8081:80"
        env_file:
            .env
        environment:
            PMA_HOST: ${DRUPAL_DB_HOST}
            PMA_USER: ${DRUPAL_DB_USER}
            PMA_PASSWORD: ${DRUPAL_DB_PASSWORD}
            PMA_ABSOLUTE_URI: http://localhost:8081/
        depends_on:
            - db

volumes:
    db_data:

The MySQL Image

You will see that I used MySQL 5.7 in this configuration to simulate an outdated environment. MySQL 5.7 reached its end of life in October 2023 but as of late-2024, we have clients who, for one reason or another, are still running MySQL 5.7. They are not alone. A September 2024 article from Percona, a database software and support company, has a FAQ section titled, "Should I upgrade from MySQL 5.7 to 8.0?" Clearly, a large percentage of sites are still running legacy databases on their web stack.

If you are using MySQL versions 8.x, visit Docker Hub's MySQL repository to see the relevant image tags. You will need to update this section:

    db:
        image: mysql:5.7

Also, most development machines will already have a MySQL server running on the local port 3306. To avoid conflicts, this docker-compose.yml maps the container's MySQL port to the local port 3307. Adjust this to suit your own setup.

        ports:
            - "3307:3306"

7. Build and Start the Environment

Now you're ready to build and start your environment. Open up a terminal and run the following command:

docker compose up -d --build

This will use Docker Compose to build the containers and run them in detached mode. It may take a few minutes to complete if you're running this command for the first time. Docker will need to download all the images from the Docker repository before building.

8. Access Your Local Drupal Setup

If all goes well you should have your environment ready to install Drupal 7. Visit http://localhost:8080 in your browser to access the Drupal 7 instance running in the Docker container.

Follow the installation wizard and Use these database settings in your .env file.

6. Testing and Workflow

You can use these commands to test your installation. Check the documentation in the Additional Resources section below for more commands.

Basic Testing

Container Status:

# Check if all containers are running
docker compose ps

Expected output: db, drupal and phpMyAdmin services should show "Up" status

Drupal Installation:

Access the Drupal site at http://localhost:8088
You should see the Drupal installation page or site
Check error logs if needed:

docker compose logs drupal

Drush Functionality:

# Test Drush status
docker compose exec drupal drush status

# Test Drush version
docker compose exec drupal drush --version

# Test site-specific Drush commands
docker compose exec drupal drush core-status

Composer Functionality:

# Test Composer version
docker compose exec drupal composer --version

# Test Composer diagnostics
docker compose exec drupal composer diagnose

Database Connection:

# Test database connection via Drush
docker compose exec drupal drush sql-connect

# Test phpMyAdmin access
# Visit http://localhost:8081

Testing Your Migration Utilities With Sample Content

You can use Drush to generate sample content. This can be useful for testing your migration utilities.

1. Log Into the Container's Terminal

docker compose exec drupal bash

2. Install Helper Modules

Install the devel, devel_generate, and taxonomy_manager modules:

drush en devel -y
drush en devel_generate -y
drush en taxonomy_manager -y

Devel Module: The Devel module is a comprehensive toolkit for Drupal developers that offers several submodules and features to aid in development and debugging.
Devel Generate Module: The Devel Generate module is a submodule of the Devel module, specifically designed for generating dummy content.
Taxonomy Manager Module: Use the Taxonomy Manager module to mass insert taxonomy terms.

3. Generate Sample Content

Now generate some sample content:

# Generate nodes with randon content
drush generate-content 500

# Generate users
drush generate-users 25

# Generate taxonomy terms
drush generate-terms tags 20

# Generate nodes for a specific content type
drush generate-content 20 --types=article

# Generate comments on random nodes:
drush generate-comments 250

Development Workflow

Here are some basic commands to support your development and migration workflow.

Starting/Stopping Environment:

# Start containers
docker compose up -d

# Stop containers
docker compose down

# View logs
docker compose logs -f

Using Drush:

# Access Drush
docker compose exec drupal drush

# Clear cache
docker compose exec drupal drush cc all

# Update database
docker compose exec drupal drush updb

Working with Composer:

# Install dependencies
docker compose exec drupal composer install

# Add new package
docker compose exec drupal composer require [package-name]

Service Access:

Drupal: http://localhost:8088
- Username and password as set during the installation process.
phpMyAdmin: http://localhost:8081
- Username: (from .env)
- Password: (from .env)
MySQL: localhost:3307
- Username: (from .env)
- Password: (from .env)

Database Operations:

# Export database
docker compose exec db mysqldump -u [user] -p[root-password] drupal > backup.sql

# Import database
docker compose exec -T db mysql -u [user] -p[root-password] drupal < backup.sql

7. Preparing for Your Drupal 7 Migration

If you made it this far, you will have a fully working and tested Docker container with Drupal 7, access to the database, and some basic tools to support migration or upgrade tasks. This environment isolates your development work, ensuring that your live site remains unaffected throughout the process.

Importing Your Live Drupal Installation into the Container

To get started with your migration project, you'll need to transfer your existing live Drupal installation into the container. The Drupal 7 documentation for migrating a site between environments will give you an outline of the steps.

As a summary, you begin by exporting the database and files from your live site. Once you have these, you can load the database into the container's MySQL instance and place the site's files in the ./src directory on your host filesystem. (Remember, we created a bind mount to map the ./src directory to the container's web directory at /var/www/html.) This gives you a working copy of your live site, but in a safe, sandboxed environment.

Important note: In this article we used Drupal 7.103 for our container. To avoid problems with version conflicts, you should update your live Drupal site to the same version before exporting.

Creating a Pristine Snapshot

Before diving into migration tasks, it's a good idea to create a snapshot of the container in its pristine state. This serves as a clean starting point you can revert to if anything goes wrong during the migration process. A snapshot ensures you won't need to repeat the setup steps from scratch if you need to restart or experiment with different migration approaches.

You create a snapshot by committing the current state of your container to a new Docker image. I'll cover this in a separate article but at this stage you will now be ready to use whatever tools you need to upgrade or migrate your Drupal 7 installation.

Migration Options

Instructions for the migration itself will need to be covered elsewhere as it's a very detailed process. However, you can check these resources for your migration options:

Upgrading to a newer version of Drupal: You can use your container to trial-run the upgrade steps in the Drupal documentation, "Upgrading from Drupal 6 or Drupal 7."
Migrating to another platform: If you plan to migrate to another platform such as WordPress, please see our Drupal to WordPress Migration Guide.

8. Conclusion

Docker provides a very practical and reliable way to set up migration environments. While it requires an initial investment in learning, the long-term benefits include consistent workflows, reliable environments, and over-all, fewer frustrations when getting started with a migration project. Docker won't solve every migration challenge, but in my experience, it definitely simplifies many of the technical hurdles involved.

If you're facing challenges with Drupal 7 migrations or need expert assistance, reach out to us. We can help make your next project smooth, efficient, and future-proof.

Additional Resources

Need Help With Your Drupal 7 Migration?

I specialise in complex Drupal to WordPress migrations, including setting up Docker-based development environments, custom migration scripts, and zero-downtime launches. Get a free, no-obligation consultation.

Get a Free Quote

How to quickly migrate your WordPress site using the Backup Migration plugin

Anthony Lopez-Vito — Sat, 28 Oct 2023 10:56:11 GMT

This WordPress migration guide using the Backup Migration plugin is a non-sponsored guest post by Emma from BackupBliss, creator of the plugin.

You may not have heard of BackupBliss as, it being a relatively new entrant to the backup and migration plugin space, doesn't appear in the usual 'top plugins' style articles. Nevertheless, I have personally used the Backup Migration plugin and find it a good alternative to more familiar names such as All-in-One WP Migration, BlogVault and UpdraftPlus. My standard plugin for many years has been BackUpWordPress, formerly by Human Made and then taken over by XIBO Ltd. Unfortunately, XIBO seems to have abandoned the plugin so I am now looking for a replacement. I am hopeful that BackupBliss may be a contender.

Read on for the main article.

Migrating your WordPress site using the Backup Migration plugin by BackupBliss

Migrating today’s average WordPress site, which has around two dozen plugins and weighs about 1GB, can be a swift task for site owners looking for an easy solution through a plugin. In this article, I will guide you through the steps that will lead you to a successful website migration with the free Backup Migration plugin.

Migration with a plugin usually works flawlessly when done on common hosting providers, and when the website uses up-to-date components such as the latest WordPress and PHP versions, as well as widely used page-builders, themes, and plugins.

However, things might get tricky when in play is outdated software, large databases, highly customized themes, etc. In such cases, and in all other cases where you get stuck with the website migration, I recommend that you turn to a professional.

Preparation

The whole process of WordPress site migration with a Backup Migration plugin basically consists of two parts - backup creation on the old site and backup restoration on the new site (migration). But let’s mention first a couple of things you should do before migration:

1. Installing the Backup Migration plugin on the old site. You can search for and install it as any other free WP plugin, in the website’s Dashboard section “Plugins”.

2. Setting up a fresh WordPress instance in the place where the new site will be. Most of the big hosting companies have a one-click solution for this, but it is also not too hard to set it up yourself if an automated option is not available to you. You will also need to add a Backup Migration plugin to that instance, the same as on the old site.

3. Excluding unnecessary files from the migration. As a variation of a clean-up, it might be a good time to think about the unused files and plugins that you have on your old site and perhaps add a few exclusion rules when you start creating a website backup in the following chapter.

Backup creation

The website backup is created in a couple of steps:

1. Once you have the Backup Migration plugin installed on your website, it will automatically redirect you to its menu page within the WordPress Dashboard. Navigate to the plugin area “What will be backed up?”, where you should checkmark all files, folders, and complete database, and click on the Save button. This assures that a full site backup will be created.

In this menu, you will be able to see the raw sizes of folders and databases that are on your site. It might give you an idea if there is something that you want to exclude. To exclude any specific files and folders, turn on the option for it to “Yes” and carefully compose the list.

By default, this plugin will already suggest some common exclusions, and provide examples on how to make some of your own. Remember to Save these settings if you make any changes.

2. Click the “Create backup now!” button, and the plugin will swiftly commence the backup process, typically wrapping up in just a minute or two for average websites. The duration primarily depends on the database size and server setup. If you're dealing with larger sites exceeding 2GB, consider the premium Backup Migration plugin for enhanced performance. Once the backup process concludes, you'll have the option to download the backup file, a highly advisable practice for preserving a local copy of your backup.

Migration job

The second major part, the migration process is taking place on the destination site, which we mentioned in the Preparation section of this article.

Here are the steps to be taken on this site:

Navigate to the plugin area “Manage & Restore Backup(s)”, where there are three options to restore a backup from the source site. In cases when the site is being moved to a new domain, option A is a fitting choice, and for the cases when domains remain unchanged, then options B or C are more appropriate, as in these cases, site owners will need to take down the source site before making the new website go live

A. Super-Quick Migration: To use this functionality, simply paste the link to the backup file from the source website and click the "Restore Now!" button. You can obtain these backup links in the same plugin section under "Manage & Restore Backup(s)" by clicking the small link icon.

B. Upload Backup Files: To use this option, you can manually upload backup (zip) files within the same plugin section. You have the choice of selecting the file or using a drag-and-drop method. After successfully uploading the backup file, initiate the restoration process by clicking the "Restore" button located on the right side of the listed backup file.

C. External Storage Location: If you prefer to store your backups in an external location, you can select options like Google Drive (others are yet to come). To use this feature and synchronize your backup files across your online websites, connect your Google account in the Backup Migration plugin section titled "Where Shall the Backup(s) Be Stored?". Once the Google account is connected and the backup file is synchronized, start the restore process by clicking the "Restore" button in the "Manage & Restore Backups" plugin section.

If you have migrated your site with option A, and after you have checked out the new site, you may want to archive the old site. Nevertheless, if you want to want to keep the old site online, it's typically recommended to configure suitable redirects from the old domain to the new one.

Thankfully, Inisev, a company that developed the Backup Migration plugin, offers a user-friendly Redirection plugin for this purpose, featuring a recognizable intuitive interface that enables a swift and efficient setup of redirections.

Post-migration

Once the migration work is over, you might want to keep the Backup Migration plugin on your new site, for multiple reasons.

The most important one is that you can create regular website backups with it, which can also be scheduled, so you will not have to stress out in case something goes bad on the site and it becomes broken or even unavailable to the users. Though most of the big hosting companies offer the backup option, the solution from the plugin might be a quicker and more user-friendly way to restore your website, especially if you are not a tech-savvy person.

The Backup Migration plugin can also easily create a staging site for you, so the big changes that you plan for your website will not pose a threat to it, as you can test it all out safely on the staging environment.

Final Thoughts

Migrating a WordPress with a plugin can turn out to be a seamless task. However, it has to be kept in mind, that there are tens of thousands of combinations of servers, hosting providers, and WordPress sites and that migration tools are impossible to optimize to do the job flawlessly on each combination. This is just one of the reasons why having top-notch professionals for help is important, and if you are in such need - you know where to contact us.

This is a non-sponsored guest post by Emma from BackupBliss.

Fixing Access Forbidden (403) issues after migrating WordPress to a static site

Anthony Lopez-Vito — Thu, 09 Feb 2023 01:15:57 GMT

After migrating a WordPress site to static files, Google Search Console may start sending you notifications about page indexing problems. Often the issue will be marked as 'Blocked due to access forbidden (403)', a fairly common error that can have different causes, depending on how your website and server is set up.

This article specifically deals with the case when:

You previously had a working WordPress installation;
You migrate the site to static HTML files on an Apache web server;
Google Search Console starts complaining about page indexing problems.

If this does not apply to your situation, the proposed solution may not work but you will still find the explanation useful in diagnosing the problem.

The Forbidden 403 error

Being in the 4XX category of HTTP response codes, Access Forbidden (403) is a client-side error that may show in a message similar to the following combinations:

Access Forbidden (403)
403 Forbidden
HTTP 403
HTTP Error 403 – Forbidden
Forbidden: You don't have permission to access [directory path] on this server

The Google Search Console notification email will be about page indexing problems with 'Blocked due to access forbidden (403)' as one of the Top Issues.

A typical Access Forbidden (403) notification from the Google Search Console

Nevertheless, it being a client-side error doesn't necessary isolate the problem to your browser. Many solutions online will advise you to clear your cache or refresh the page. This is easy to do and usually a sensible first step but if you found the issue via a Google Search Console notification after a WordPress migration, these recommendations won't help.

The 403 response code essentially means that a web client, such as your browser, does not have permission to access the requested resource. The web server understands the request but can't allow access due to file permissions settings or a server misconfiguration. When it comes to WordPress, the error will almost certainly be due to a misbehaving plugin, a corrupt .htaccess file or incorrect file permissions. However, if you've recently converted your WordPress installation to a static site, the error will most likely have a different cause.

To understand why the Access Forbidden error happens, it's worth reviewing the differences between how the WordPress content management system (CMS) serves content and how a static site responds to web client requests.

How WordPress serves your browser requests

WordPress is a database-driven Content management system (CMS). Most of the content is stored in a database and URLs generally do not correspond to any files in the web server's filesystem. Instead, URLs are external references to the database content. WordPress calls these references permalinks and its rewriting engine uses internal rules, specified in the permalink settings, to build permalinks dynamically. When a client requests a page from the site, WordPress takes care of serving the correct content. Included with the pages will be any XML-based RSS (Really Simple Syndication) feeds. WordPress will send the HTML page or an XML feed, depending on what the client requests.

For example, if you set the permalink settings to the Post name structure, WordPress will generate a HTML post when you browse to the following URL:
https://example.com/your-post/

The RSS feed for that post will be at:
https://example.com/your-post/feed/

RSS feeds are normally parsed by an RSS client rather than for displaying directly in the browser window so requesting the RSS feed resource will not send HTML. Instead WordPress will generate XML for the feed.

Serving static files

By definition, static sites have no way of dynamically generating content based on the browser request. You make a request to the web server at a given URL and if the resource is present with the correct access permissions, the web server will go ahead and serve the file. The URL for a static site will normally look something like:
https://example.com/your-post.html.

If you have an RSS feed, it might look something like:
https://example.com/feed.xml.

Notice that the request includes the path to the file, such as your-post.html or feed.xml. The file is not present in a WordPress permalink because, as mentioned previously, it is only a reference to the actual content stored in the database.

Web server directory index

Web servers such as Apache also have a Directory Index directive. This is a configuration that can set the server to automatically send a file when a client makes a request without a filename in the URL. The file known as the directory index and is normally named index.html.

Web servers such as Apache also have a Directory Index directive. In the early days of the web, you could browse to a folder in the web server filesystem and get a listing of all the files present. For security, most web hosts now disable this feature for most of their hosting services. The Directory Index directive is a configuration that can set the server to automatically send a file when a client request only includes the folder name in the URL. For most hosting services, the standard directory index files are normally index.html and index.php.

Say a client makes a request for the following:
https://example.com/docs/

If the directory index is set to index.html, the server would return:
http://example.com/docs/index.html.

The index.html renders as a web page in the browser. Directory index resources can also be set to other file types like index.txt or index.xml.

Generating static HTML files from a WordPress site

WordPress plugins such as Simply Static will crawl your site to generate static HTML file copies for the pages. Since WordPress includes RSS feeds, static XML copies will also be generated for these feeds. The tables below show typical WordPress permalinks and their equivalents after static HTML copies are generated.

Page type	WordPress permalink
Page content	`https://example.com/your-post/`
RSS feed	`https://example.com/your-post/feed/`

Page type	Static file URL
Page content	`https://example.com/your-post/index.html`
RSS feed	`https://example.com/your-post/feed/index.xml`

Once again notice that the static site specifies the filename in the path whereas the WordPress permalink, when set to the Post name structure, does not.

Why access is forbidden

We have all the puzzle pieces to understand why you would get the Access Forbidden (403) error and how you can fix the problem. After you migrate your WordPress site to static files, the old permalink paths to pages will still serve a web page because most hosting providers have index.html as a directory index resource.

You can request the URL in the WordPress post name permalink format:
https://example.com/your-post/

The static file generator would have created an index.html in this location:
https://example.com/your-post/index.html

The webserver sees the index.html in the filesystem and delivers it to the browser which can render the web page content. Human site visitors will be perfectly happy because they receive the web page resources they expect. However, Googlebot, Google's web page crawler, will spider through your site including the RSS feed locations. Remember, the RSS feed folders will contain an index.xml. XML files are not normally a default directory index resource for most web hosts. Since there is no index.html file in the feed folder, the web server thinks it's being asked to deliver a file listing. Again remember that file listings are disabled by most web hosts for security. Thus you get the error:

Access Forbidden (403)

You are forbidden by the web server to access that folder listing.

How to fix the Access Forbidden (403) error

Now that we know exactly why we get this error we attempt a fix. If your host runs Apache, the solution will likely be simple. Edit or create the .htaccess file in the root of your site and add index.xml to the list of directory index resources. For example, if it not already there, add the following line somewhere near the top of the file:

DirectoryIndex index.html index.php index.xml

The index.xml in the list will tell Apache to serve the XML file when Googlebot requests the RSS feed directory. While you're doing this, inspect a few o the feed directories to make sure the index.xml files have the correct permissions (usually 775 for most server setups) and the correct ownership. The ownership settings should be:

user is the user account with root privileges on your web server.
group is usually www-data or apache but you may need to check this with your hosting provider.

You can test your changes by pointing your browser to a few feed directories to see if the server returns XML. Remember to leave out the index.xml file and specify the directory only. For example:
https://example.com/your-post/feed/

If your browser displays the RSS feed XML, you know the problem has been solved and can be reasonably confident that Googlebot won't encounter the 403 error.

This may not work if you're running a VPS server for your site where some more in-depth configuration may be needed, such as editing your Apache configuration files. Also, .htaccess is not used by other web servers such as NGINX. In these cases, your next port of call should be to contact your hosting provider. Tell them that you would like to add index.xml to the directory index resources so that the XML file is served when a visitor lands in a directory. Most good hosting companies will be able to guide you on your options or make the change on your behalf. After you've applied the fix, be sure to go to your Google Search Console to revalidate the affected page.

Photo by Lucian Alexe on Unsplash

How to set up a MySQL database server on Ubuntu for Drupal to WordPress migrations

Anthony Lopez-Vito — Fri, 11 Jun 2021 15:44:52 GMT

Content Management System (CMS) migration projects involve moving data between databases with different schemas. Table names, field types and constraints often don't match up, leading to a number of frustrating errors. This is especially the case with highly complex Drupal to WordPress migrations that use custom scripts to extract, transform and load the data. These projects can seem like you're constantly hitting roadblocks throughout. I've found from experience that running the migration in an appropriate development environment can reduce a great deal of effort. In this guide, I will describe how to set up a MySQL database server on Ubuntu for Drupal to WordPress migrations.

Why MySQL and Ubuntu?

The first thing to address is why MySQL and Ubuntu? How about MariaDB? How about Arch Linux, Mac OS or Windows? Yes! Any platform that runs Drupal and WordPress will work for your migration environment so you can use whatever you prefer. Personally, I have a fondness for OpenBSD but it's not a practical platform for a CMS migration. OpenBSD's niche user-base means you'll spend much longer installing necessary tools and troubleshooting errors.

There are all sorts of tutorials covering MySQL on Ubuntu. This means you're more likely to quickly find a solution from a web search when you hit a problem. Furthermore, if you need a software utility or program to help you get the job done, it will probably be available through apt, dpkg, snap or tasksel. Use whatever you like but for now, MySQL on Ubuntu is my recommended platform for Drupal to WordPress migrations. I expect this will be the case for some time to come. These projects are complex and time-consuming enough without making the job more difficult.

Installing MySQL on Ubuntu for CMS migrations

There are many detailed tutorials for installing MySQL on Ubuntu. DigitalOcean's How To Install MySQL on Ubuntu 20.04 is a good one and writing another won't add much value. My guide will therefore only give a brief overview of the MySQL server installation steps. Instead, I will focus on the configuration areas specifically related avoiding problems on a CMS migration project.

You may wonder why the migration environment should be much different from a live server. Migration projects require you to do things that aren't supported by the CMS platform. You're therefore likely to encounter weird errors that aren't normally found when running standard Drupal or WordPress.

Set up your Ubuntu LAMP migration platform

The main source of unusual errors is almost certainly because you're migrating on a setup suited to a live website. Live server configurations are more restrictive than you need for a migration project. You can therefore save yourself a huge headache by rolling your own local migration environment. It might take a little longer to get started but you'll save time by avoiding lots of unnecessary troubleshooting.

I must highlight that this will be a local migration environment and should not be accessible from the public internet. The normal security considerations with running a live content management system don't apply when you're working locally. By all means follow basic security measures mentioned the various tutorials for setting up Ubuntu and MySQL. Nevertheless, a highly secure setup is counterproductive for these projects and you can avoid trouble by being a little more permissive.

Go ahead and install Ubuntu Desktop. Since this will be a development environment, you'll want the Desktop environment rather than the more lightweight server version. Of course, you'll still need to install a web and database server. Follow these instructions for installing LAMP stack but skip the step of installing MariaDB. As mentioned above, we'll be using MySQL.

WARNING: Installing MariaDB over MySQL or vice versa on Ubuntu 20.04 may lead to all sorts of problems starting up the database server with errors like the following:

Failed to start mysqld.service: Unit mysqld.service not found.

The last time I did this, none of solutions mentioned online for purging the installation worked. I spent most of a day trying to fix the problem. In the end, I realised it was quicker to start again and rebuild the machine from scratch. This is a big reason why I decided to stick with MySQL as standard for my projects.

Install MySQL

You can read a more detailed tutorial on installing MySQL on Ubuntu but here's an overview.

Update the package index on your server: sudo apt update
Install MySQL server: sudo apt install mysql-server
Secure MySQL: sudo /usr/bin/mysql_secure_installation

The mysql_secure_installation script doesn't cause problems for migrations so it's worth running.

Create an admin user:

CREATE USER 'user'@'localhost' IDENTIFIED BY 'userpassword';
GRANT ALL PRIVILEGES ON *.* to 'user'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;
quit;

Now create a user and database for your migration project:

CREATE USER 'projectuser'@'localhost' IDENTIFIED BY 'password';

CREATE DATABASE project_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;
GRANT ALL ON project_db.* TO 'projectuser'@'localhost';

You can give this user more restrictive permissions but GRANT ALL avoids errors when running scripts and SQL queries on the database. Only the migration team should have access and you won't need it after the migration so why not make your life easier?

Setting the MySQL server SQL mode

It's possible that you won't be familiar with SQL modes unless you've done some database administration work. For our purposes, SQL modes do two things:

change the types of queries you can run on your MySQL server;
change the validation checks when altering the data.

I've found that specific SQL modes need to be set for Drupal to WordPress projects. You may find that all sorts of strange errors appear if the correct modes aren't set. The following sections show you two ways to set your MySQL server's SQL mode.

Option 1: Setting the global sql_mode in the database

Login in to database as an admin user.
View the current sql-modes using SELECT @@GLOBAL.sql_mode; and make a copy if necessary.
Copy the current modes (add or delete modes as needed) and paste in next step.
Add ALLOW_INVALID_DATES and removes both NO_ZERO_DATE, NO_ZERO_IN_DATE by setting the sql-modes with
SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,ALLOW_INVALID_DATES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'; (WARNING: check the modes correspond with your setup.)
Restart server:
sudo systemctl start mysql

Option 2: setting the sql_mode in the MySQL configuration file

Locating the MySQL configuration file

The my.cnf configuration file isn't always found in the same place. It's specific to the Linux distribution and server configuration but can normally found in one of the following locations:

/etc/my.cnf
/etc/mysql/my.cnf
echo/my.cnf
[datadir]/my.cnf
~/.my.cnf

If you can't find your MySQL configuration file, you can try running locate my.cnf or mysqladmin --help. The latter will show something like the following in the output:

Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf

Also keep in mind that it's possible to use !include directives to include other option files and !includedir to search specific directories for option files. Under Ubuntu, there may be a file /etc/mysql/my.cnf with !includedir directives to search /etc/mysql/conf.d/ and /etc/mysql/mysql.conf.d/

Editing the MySQL configuration file

If the MySQL server finds more than one configuration file, it will load each one in turn. The values override each other and it can be difficult to know which takes priority. Furthermore, the --defaults-file parameter can also override all configurations. Keep things simple and have only one file and place it the directory that makes sense to you.

Before editing the my.cnf, first log in to MySQL with an administrator user and run the SELECT @@GLOBAL.sql_mode query to see the values used in your setup.

Running the SELECT @@GLOBAL.sql_mode query on MySQL Workbench

Next, open the configuration file, look for the section [mysqld] and edit the line starting with:
sql_mode = ...

Add the line if it's not there. Adjust the exact modes to match your project's needs so take a look at the list of SQL modes to see which may apply. I've found the following works well:
sql_mode = "STRICT_TRANS_TABLES,ALLOW_INVALID_DATES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"

Finally, restart the MySQL server. On Ubuntu this will probably be with

sudo systemctl start mysql

If you are logged in to the MySQL server, you may also need to disconnect your client and reconnect for the changes to take effect for your session.

Potential errors

Here are some potential errors that you may come across during a CMS migration project. I usually find them when running a Drupal to WordPress migration on a freshly built development environment.

mysqldump access denied when trying to dump tablespaces

Migrations involve dumping and importing databases and this process is straightforward on a mature development environment. However you may receive an 'Access denied' error out of the blue when dumping your MySQL database:

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces

If you see this, perhaps you were working on an environment that was a little too 'mature' (in other words, obsolete!) and you have recently upgraded your installation. The updates for MySQL 5.7.31 and MySQL 8.0.21 in July 2020 introduced an incompatible change that produces this error.

The fix involves granting the PROCESS privilege to the user running mysqldump, or using the --no-tablespaces flag.

ERROR 1067 (42000) Invalid default value

Drupal nodes store the date as a Unix timestamp in an int (e.g. 1623427200) field whereas WordPress stores dates as datetime (e.g. 2021-06-11 16:00:00). There may be a conversion error in your migration script or the source date could simply be zero for some reason. Normally your MySQL server mode will be set to NO_ZERO_DATE, NO_ZERO_IN_DATE so trying to insert a zero date will give you the error:

ERROR 1067 (42000) Invalid default value

You can fix this by replacing NO_ZERO_DATE, NO_ZERO_IN_DATE with set to ALLOW_INVALID_DATES in your global SQL mode.

Expression #1 of SELECT list is not in GROUP BY clause

You run an SQL query and get the rather cryptic error:

Expression #1 of SELECT list is not in GROUP BY clause and contains
nonaggregated column 'database.table.pid' which is not functionally dependent
on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

What's wrong? MySQL has a only_full_group_by mode which, when enabled, strictly applies ANSI SQL rules when using GROUP BY. Fix this by reworking your script or removing the ONLY_FULL_GROUP_BY SQL mode.

Error Code: 2013. Lost connection to MySQL server

This often happens when an SQL query takes too long to return data. The connection between your MySQL client and database server times out so the connection gets dropped. You can try increasing the net_read_timeout and net_write_timeout values in your MySQL configuration, or optimising the query itself.

Conclusion

Setting up a MySQL database server for Drupal or WordPress is a familiar task for web developers and site administrators. However, CMS migrations have quirks that can cause obscure and baffling errors. In this guide I've shown you some little tricks that may save time and annoyance. While there's no way to provide an exhaustive list of solutions to all the MySQL problems you'll encounter, I hope to have pointed you in the right direction.

If you have a site migration project and would like to hire me, please ask for a quote for my consulting service.

Cover photo by Rubaitul Azad on Unsplash

Need Help Setting Up Your Migration Environment?

I specialise in complex Drupal to WordPress migrations, including database configuration, custom SQL scripts, and troubleshooting tricky migration errors. Get a free, no-obligation consultation.

Get a Free Quote

How to fix the mysqldump access denied process privilege error

Anthony Lopez-Vito — Fri, 23 Oct 2020 15:23:45 GMT

How to fix the mysqldump process privilege error after applying a recent MySQL update. You may receive a new 'Access denied' error when trying to dump your MySQL database:

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces

You were able to export database before so what caused this? Here's the answer: updates for MySQL 5.7.31 and MySQL 8.0.21 in July 2020 introduced an incompatible change:

Incompatible Change: Access to the INFORMATION_SCHEMA.FILES table now requires the PROCESS privilege. This change affects users of the mysqldump command, which accesses tablespace information in the FILES table, and thus now requires the PROCESS privilege as well. Users who do not need to dump tablespace information can work around this requirement by invoking mysqldump with the --no-tablespaces option. (Bug #30350829)

This error appears when running mysqldump directly from the command line, exporting the database using a client like MySQL Workbench or if you're managing the WordPress database through WP-CLI's export command. In my case, I encountered the problem when running a routine Python script for a Drupal to WordPress migration client. My script uses WP-CLI to export a database dump file and deploy it to a remote server.

Solutions for fixing the mysqldump process privilege error

The mysqldump command requires at least the following privilege assigned to the user:

SELECT privilege for dumped tables
SHOW VIEW for dumped views
TRIGGER for dumped triggers
LOCK TABLES if you don't use the --single-transaction option
PROCESS if you don't use the --no-tablespaces option

The last PROCESS privilege is new as of MySQL 5.7.31 and MySQL 8.0.21 and may be the root source of your problem. You can solve the mysqldump process privilege error in two ways:

Updating the privileges for your database user.
Runing mysqldump with the --no-tablespaces option.

Solution 1: Update the user privileges

Granting the PROCESS privilege for the user is perhaps the simplest option for fixing the mysqldump process privilege error. Keep in mind that this option presents security issues. You should therefore really only use this option for your own local development server installation. To grant the PROCESS privilege, log in as an administrator user and run the following query: GRANT PROCESS ON *.* TO user@localhost; Note that PROCESS is a global level privilege. It can't apply to individual databases. Global privileges are either administrative or apply to all databases on your MySQL server. Trying to grant them on individual databases deplays the following error: ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES To grant the privilege to all databases you must use the ON *.* ... syntax.

Solution 2: Use the `--no-tablespaces` option

If you cannot assign global level privileges to your user, for example, when doing so presents unacceptable security issues, you must specify the --no-tablespaces option when dumping your database. mysqldump --no-tablespaces -u user -ppass dbname > db_backup_file.sql

What are MySQL tablespaces?

We are usually only concerned with logical database objects when working with databases. However, the data must be physically stored somewhere. This is where tablespaces come in. Tablespaces are physical datafiles stored in the host file system holding data for one or more tables and indexes. The diagram below provides a handy illustration. It's from the Oracle Concepts documentation, Introduction to Tablespaces, Datafiles, and Control Files and refers to Oracle databases. Nevertheless, it may help you understand how tablespaces relate to logical database objects and datafiles. [caption id="attachment_3378" align="aligncenter" width="522"] Diagram source: Oracle Concepts documentation[/caption] You can therefore use the --no-tablespaces option if you don't need to dump tablespace information. This may be the case for routine database dumps, for example when exporting databases for WordPress migrations.

About the access mysqldump denied PROCESS privilege error

mysqldump accesses tablespace information in the FILES table. Prior to MySQL 5.7.31 and 8.0.21, your user could run mysqldump without the PROCESS privilege. However, users running mysqldump after the update need PROCESS privileges to access the INFORMATION_SCHEMA.FILES table. Running mysqldump without PROCESS privilege ends up giving you an Access denied error.

Be careful with the PROCESS privilege

According to the MySQL documentation, the PROCESS privilege controls access to information about statements being executed by sessions. It is a server administration privilege and should not be given to all users. This is because it may show text from currently executing queries. Any user with the PROCESS privilege may therefore see queries issued by others. Here's the danger: these queries, such as UPDATE user SET password=PASSWORD, may show secrets. For more information, see General Security Issues and the MySQL Access Privilege System from the O'Reilly MySQL Reference Manual.

A guide to WordPress Backups and Staging

Anthony Lopez-Vito — Tue, 11 Feb 2020 12:59:11 GMT

This WordPress Backups and Staging Guide is a guest post by Melinda Bartley.

If you've run a WordPress site long enough, you'd know how making changes to it can be tricky. Sometimes, even minor changes can cause major glitches. This makes backups and staging such lifesavers!

Every WordPress site should have backup and staging solutions in place. And not just any solution, one that actually works! I say this because in my experience, relying on host backups and staging environments have too many limitations and a tedious process. So I turned to plugins, but there too, I found so many options, it was hard to pick the right one.

In my quest to get a permanent solution, I stumbled upon BlogVault. It was easy-to-use and reliable with a great support team behind it. Ever since, it has been my go-to for WordPress backups and staging.

So today, I'm sharing everything what I think WordPress site owners should know about backups and staging and why BlogVault works best.

Let's begin with a few basics.

Difference Between Backup and Staging

Many ask If I have a backup, why do I need staging? Well, the two solve very different problems. Backups are for reverting to a previous version when a problem arises on the site.

For example, you run an update on your website and it causes your site to malfunction. You find that plugins are not compatible with the new version of WordPress. It would take considerable time to update these plugins or find replacements. To solve the issue immediately and get your site back to normal, you can restore your backup.

Backups come in handy when things go wrong such as botched updates, human errors, presence of malware, and so on.

Coming to staging, it enables you to create a clone of your WordPress website. This is done specifically for development. You can try out new themes, plugins, designs and layouts. You can test out updates and even test restore your backup! None of the changes you make will affect your live site.

There are staging solutions that have a feature to merge your changes. This is extremely handy because you might make multiple changes and it would take time to replicate the same on your live site. So you can just push the changes to your live site. Simply put, staging enables progress!

Now that you know why you need both solutions, let's check out the backup solutions available for WordPress sites.

WordPress Backup Solutions

There are many options to backup your WordPress site, but not all of them are easy to use or reliable. The main options available to back up your site are – manually, using a plugin, or through your web host.

Manual Backups

For this, you need to access your web hosting account. Once you've logged in, go to cPanel > File Manager > Public_Html. Here, you'll see all your WordPress files. Simply compress and download them.

(Image source: WP Engine)

It seems simple enough. But there are issues with this method. For one, the process is time-consuming. Spending time taking manual backups regularly is simply not feasible when you have tons of other things to focus on. Plus, you need to take responsibility to encrypt your data and store the backup locally. A backup has all the information on your website and needs to be stored securely. If hackers get their hands on an unencrypted backup, it's already a data breach, but you can be sure your site will be hacked as well.

But above all, the biggest hassle with this method is the restoration process. Sometimes, the backup just doesn't work at all. Other times, you restore your site only to find it malfunctioning or missing functionalities. Which means more time wasted on troubleshooting and debugging troubles. This is why I prefer using a plugin. But among these too, there are so many options available, how do you choose one?

Well, after trying out a couple of them, I stuck with BlogVault. It's great for backups and even offers inbuilt staging at no additional cost.

Backups with a WordPress Plugin – BlogVault

To start off, setting up BlogVault was easy to use – with a simple install and activate process. Once you sign up, the backup automatically runs. It gives you the following options which I think is not only cool but essential for WordPress:

- The option to schedule your backups. Plus, you can take a backup on demand whenever you want, any number of times. This is good to have when you want to make major changes to your site or roll out big updates. Taking a backup before any major change is absolutely necessary.
- It's all automated so you don't have to worry about the technicalities.
- The restore process is just a few clicks. It takes a few minutes and it's guaranteed to work. So you needn't worry about your site breaking or losing data.
- The process is handled offsite on their own servers so it doesn't affect the performance or speed of your site. Plus, it doesn't take a full backup every single time. It smartly copies one full backup and then subsequently, only the changes made each time are backed up.
- Lastly, your backup is encrypted and multiple copies of it are stored securely. That takes away the pain of storage.

Apart from this, there are handy features like 365-day archives, real-time backups, website management, site migrations, multiple site management, uptime monitoring, and staging.

Next, you can also back up your website using your web host itself. I've checked out two of the most popular ones.

Backups with your Host – WP Engine

WP Engine takes backups for all environments by default. This includes production staging, development, and legacy staging. It's automated, encrypted, and stored offsite on Amazon S3. You can also take manual backups. It keeps up to 40 backup points. Older data up to 60 points may be accessible but you need to contact their support team for that.

To access a backup, log into your user portal. Go to sites > environment name > backup points. You'll find your backups here. You can also create a backup on demand.

To restore, simply click on the backup point you want and click the Restore button.

(Image source: WP Engine)

The process seems simple enough. But WP Engine also has some drawbacks. The restore process can take several minutes to several hours. And it's important to note that they do not copy all files of your site. The following files aren't included:

Additionally, it's a destructive backup which means, during the restoration process, all content is overwritten. So, if you have files on your website that are not present in your backup, they will be wiped out. Your site will be restored to the contents of the backup alone.

Backups with your Host – Kinsta

Kinsta provides daily automatic backups for your WordPress site. It also has system-generated backups for all the sites listed in your account. The backup is a snapshot of your website's files, database, redirects, and Nginx configuration. When you restore your backup up, all of these elements will be rolled back to when the backup was taken.

You can also create manual backups if you want one immediately and don't want to wait for the scheduled one to run. You need to visit the 'Backups' tab, click on the 'Manual' tab. Here, you'll find the 'Backup Now' button for on-demand backups.

(Image source: Kinsta)

The duration for which your backups are stored depends on your hosting plan. It can vary between 14 days and 30 days. Kinsta also allows you to increase the frequency of your backups to hourly and 6-hour backups at a premium.

When it comes to restoring your site, you can simply click on the 'Restore' button next to the backup of your choice. While the restore takes place, you cannot access your site. The process can take a few minutes to a few hours.

What I liked about Kinsta is that it takes a backup of your site before restoration. So you can undo the restore and get back your site to as it was.

That brings up to the end of backups. With a backup solution in place, we can move on to staging. Here, I'll touch upon – the manual method, show you how you can do this with the BlogVault plugin, and also talk about staging with your hosting provider.

WordPress Staging Solutions

Staging a site can be done manually through your hosting account. But it's riddled with problems. The process to create one is quite technical, and for a regular WordPress user, it's not a feasible option.

Next, if you want to merge the changes you made, you need to download the updated files from your staging site and upload them to you live site. This is risky business as you could wipe out data and even crash your site.

Fortunately, there are other options! You can create a staging site with your host or by using a plugin. Coming back to BlogVault, it also offers a staging feature that makes the job much easier.

Staging with BlogVault

If you've already installed BlogVault, staging is a free feature compatible with any web host. On the BlogVault dashboard, you'll see an option to 'Add staging site'. It takes a few minutes, and you'll be notified when it's done.

(Image source – BlogVault)

The plugin handles migrating your site to a dev environment, so you don't have to bother about the file transfer and the database export and import. The staging site is password protected and blocked off from search engines so migration does not affect your SEO.

With everything taken care of, you simply need to start using your staging site. Once you're happy with the changes you've made, you can simply merge the changes to your live site. There's no need to upload files or replicate changes.

(Image source – BlogVault)

You can also do a selective merge. BlogVault gives you a comparison of your live site and your staging site. You can then select which changes you want to merge to your live site. In the example below, I made changes to my plugins, themes, uploads, and a few other files. But I wanted only the changes made to plugins. By clicking on the '+' sign, I could see the list of plugins I added or modified. I selected the ones I wanted and merged in just two clicks.

(Image source – BlogVault)

The best part is that you can create as many staging sites as you want. So that's BlogVault. It's straightforward and easy to use. It won't break your site when you merge the changes so your site is in safe hands.

Next, let's take a look at staging options with web hosting providers.

Staging with WP Engine

WP Engine gives you options to create three kinds of environments – production, staging, and development.

To carry out the staging process, you first need to add your site to the user portal. Next, log into the user portal and access Sites > Name of your site > Add staging. Your staging site will be created using the backup point of the existing environment.

(Image source – BlogVault)

In case you don't see the staging option, you need to convert a single environment site into a multi-environment site.

Once you've made the changes you want, you can copy the changes from staging to your production environment.

WP Engine also allows you to copy changes from a staging environment of one site to another website. This means you can roll out updates or changes to all your sites without repeating the staging process for each site. However, this can get a bit complicated and isn't recommended for those new to WordPress.

Staging with Kinsta

Creating a staging site with Kinsta is quite easy. Access your Kinsta dashboard and select your site. Here, on the top right, you have the option to create a staging environment for your website. It takes around 10-15 minutes to create a staging site.

Once you refresh the page, you will see your staging details. You can make the changes you like to your staging site and then push them to your production environment. To do this, under the 'Staging Environment' tab, there's a 'Push Staging to Live' button. Simply click on it and all the changes will be made visible on your live site.

There's no selective merge option here. So if you're pushing changes to live, be aware that all changes will be merged.

Final Thoughts

That's a wrap on backups and staging for your WordPress site. To summarize, hosts may offer free versions of backup and staging, but you're limited in terms of features and functionality. As your site grows bigger, you would need to upgrade to premium plans which are quite expensive. However, when you opt for a plugin like BlogVault, it's reasonably priced, gives you access to premium features, and above all, it works seamlessly.

Whichever be your choice, make sure you can rely on your backup to work and be restored easily. Finally, always carry out changes in a staging environment before updating your live site. This will keep you out of trouble and ensure your site is always up and running.

Ubercart to WooCommerce migration notes

Anthony Lopez-Vito — Fri, 24 Jan 2020 12:14:07 GMT

I've now had several Ubercart to WooCommerce migration projects so it's time to start documenting the process. As with all my documentation, I'll start off this post as rough notes and improve it over time. If this topic interests you, be sure to check back every so often to see the updates. Please keep in mind that I'm writing this from the standpoint of Drupal to WordPress migrations. In other words, the main objective for the projects were to migrate a Drupal site to WordPress but there was also an Ubercart to WooCommerce component.

Key differences between Ubercart and WooCommerce

There's one key difference between Ubercart and WooCommerce from an architectural point-of-view. Ubercart stores products as nodes and orders are stored in a separate table uc_orders. Orders have an order_id and there's no direct relationship in uc_orders to a product's node ID. Instead, the uc_order_products table stores the relationship between orders and products purchased with the order.

WooCommerce stores both products and order transactions as posts in the wp_posts table. The post ID is used as the order's transaction ID. Products purchased with the order are stored in wp_woocommerce_order_items, with additional product metadata being strored in wp_woocommerce_order_itemmeta.

Obviously there are many more differences but this information architecture is the key thing to keep in mind when migrating the data.

Database tables

Here are the main database tables that you'll need to migrate Ubercart content to WooCommerce.

Ubercart

Table: Drupal Ubercart tables
Table	Description
node	Products are stored in the Drupal `node` table.
uc_orders	Stores the individual Ubercart transactions.
uc_order_products	Stores the products purchased during the transaction.
uc_order_line_items	Line items for an order. This includes tax and shipping fees applied to an order.
uc_order_comments	Customer or administrator notes associated with each order.
uc_order_log	Comments about the order status by the shop administrator.
uc_zone	Country zone codes for customer billing and delivery.
uc_countries	Countries and zone codes in ISO 3166-1 Alpha-2 and Alpha-3 code format for customer billing and delivery.

WooCommerce

Table: WordPress WooCommerce tables
Table	Description
wp_posts	Stores products and transactions.
wp_postmeta	Transaction meta data.
wp_woocommerce_order_items	Stores the line items for a transaction in the `wp_posts` table.
wp_woocommerce_order_itemmeta	Stores the meta data for line items, such as quantity, price and tax information.
wp_comments	Order notes.

Order transactions and products are saved as WordPress posts. One or many order item meta entries can be linked to an order.

WooCommerce shop orders

A WooCommerce transaction is saved as a shop order in the wp_posts table.

post_status = wc_completed
post_type = shop_order

WooCommerce subscriptions

WooCommerce subscriptions are saved in wp_posts. A subscription is made up of two entries:

The transaction order for a subscription.
The subscription itself.

Subscription transaction order

post_status = wc_completed
post_parent = 0
post_type = shop_order

The subscription

post_status = wc_active
post_parent = [post ID to the transaction shop order]
post_type = shop_subscription

Products

Purchased products are saved as line items in the wp_woocommerce_order_items and wp_woocommerce_order_itemmeta tables.

A WooCommerce product can be of any post type. The product post is linked to a shop order transaction by setting the product's post ID in the wp_woocommerce_order_itemmeta table:

meta_key = _product_id
meta_value = [post ID to the product]

Notes

My apologies if you've come here looking for more complete documentation. I've been planning to write this post for more than two years but have been putting it off due to my work schedule. I figure the best way to finally get it done is to just make a start and update it as time allows.

The most-viewed articles here started off as notes for my own use and evolved over time. This one is no different. Hopefully it will still be of use to some people in its draft state.

In the meantime, you might want to take a look at these other articles and plugins.

How We Migrate: The Technical Process Behind a Drupal to WordPress Migration

Aiden — Wed, 20 Mar 2019 09:00:00 GMT

Every Drupal site is different. Custom content types, unique field configurations, contributed modules with their own database tables, and years of accumulated content that doesn't fit neatly into any template. This is why I don't use off-the-shelf migration tools. Instead, I write custom scripts tailored to each site's specific data model, and run the migration iteratively until the output is clean.

Why Custom Scripts, Not Plugins

Automated migration tools like FG Drupal to WordPress work by mapping Drupal's core database tables to their WordPress equivalents. For a basic site with standard posts and pages, this can work. However, most Drupal sites that need professional migration have outgrown standard content types.

Custom content types, field collections, entity references, paragraphs modules, and bespoke database tables. These are the structures that make Drupal powerful and that make automated migration unreliable. My approach works directly against the databases, with scripts that understand your site's specific data relationships.

Phase 1: Content Audit and Mapping

Before writing any migration code, I need to understand your Drupal site's data model in detail. This means mapping every content type, field, taxonomy vocabulary, and relationship in your database.

What the Audit Covers

Content types and their fields. Every node type and its associated field definitions: text, image, file, entity reference, date, address, and any custom field types.
Taxonomy vocabularies. The vocabulary structure, term hierarchies, and how terms relate to content.
User roles and permissions. Which roles exist, what they can access, and how they map to WordPress capabilities.
Media and files. How files are referenced, where they're stored (public vs private filesystem), and any image style derivatives that need handling.
Custom modules and tables. Bespoke functionality that stores data outside Drupal's standard schema.

The output is a mapping document that pairs each Drupal data structure with its WordPress equivalent. This document drives every subsequent decision.

Phase 2: Database Mapping

Drupal and WordPress store content in fundamentally different database architectures. Understanding these differences is essential to writing reliable migration scripts.

Core Table Mapping

At the most basic level, Drupal's node table maps to WordPress's wp_posts. Node IDs become post IDs, creation timestamps convert to WordPress date format, and the node status field translates to WordPress publish states. Content bodies come from a separate revisions table in Drupal and need joining before insertion.

Taxonomy Mapping

Drupal's term_data (Drupal 7) and vocabulary tables map to WordPress's wp_terms and wp_term_taxonomy. The relationship tables that connect content to terms require their own mapping. Drupal allows multiple vocabularies with custom fields. WordPress uses categories, tags, and custom taxonomies, each with different behaviour.

Custom Fields

This is where the complexity lives. Drupal stores custom field data across multiple tables, typically one table per field, with separate columns for each property (value, format, language). WordPress stores custom fields as key-value pairs in wp_postmeta, or in structured formats if using Advanced Custom Fields or similar plugins.

Each custom field needs individual mapping logic. A Drupal entity reference field that links to another node might become a WordPress post relationship managed by ACF, or a simple post meta value, or a custom taxonomy, depending on how the relationship is used in the front end.

Phase 3: Migration Scripts

With the mapping document complete, I write custom scripts (typically a combination of SQL and PHP) that handle the actual data transfer. The scripts work against a copy of your production database, never against the live site.

Key considerations in the scripting phase:

Data type conversions. Drupal stores timestamps as Unix integers; WordPress uses DATETIME strings. Status values, user roles, and content types all need transformation.
Character encoding. Drupal and WordPress may use different encoding for special characters, accented text, and HTML entities. The scripts handle normalisation to prevent garbled content.
Relationship integrity. Content-to-taxonomy, content-to-author, and content-to-content relationships must transfer as a connected dataset. Migrating entities in isolation breaks these links.
Media file handling. File references in the database need updating to point to WordPress's upload directory structure. Physical files are copied separately via rsync or similar tools.

Phase 4: Iterative Testing

This is the phase that separates professional migration from a best-effort attempt. I run the migration scripts repeatedly (typically 5 to 20 cycles per project), with each iteration refining the output.

What Each Test Cycle Checks

Data completeness. Did every piece of content come across? Are any fields missing or truncated?
Relationship integrity. Are taxonomy terms correctly assigned? Do author attributions match? Are related content links valid?
Visual accuracy. Does the content render correctly in the WordPress theme? Are images displaying, embeds working, and formatting intact?
Edge cases. Content with unusual characters, extremely long fields, empty values, or draft states. These are the entries that break on the first pass and get fixed in subsequent cycles.

Each cycle produces a test report documenting what was fixed and what needs attention in the next run. The site owner reviews key content at each stage to confirm accuracy.

Phase 5: URL Mapping and Redirects

Once the content migration is stable, I build the redirect map. Every Drupal URL alias is paired with its new WordPress URL, and 301 redirects are configured at the server level.

This phase works in parallel with the SEO preservation strategy. For sites with significant organic traffic, I audit the URL list against analytics data to prioritise the pages that matter most. The redirect rules are tested before launch to ensure no high-value URLs return 404 errors.

Phase 6: Zero-Downtime Launch

For business-critical sites, downtime during migration isn't acceptable. The launch process uses a staged approach:

Build on staging. The WordPress site is built and populated on a staging server, with all test cycles completed there.
Final delta migration. A last-pass script migrates any content created or updated since the previous full migration.
DNS cutover. DNS records are updated to point to the new WordPress server. The old Drupal site remains available as a fallback until the transition is verified.
Post-launch verification. Content spot-checks, redirect testing, analytics confirmation, and search console monitoring in the first 48 hours.

The total migration timeline typically runs 4 to 12 weeks, depending on the complexity of the content model, the volume of data, and the number of test cycles needed to achieve clean output.

Related reading:

Want to Understand What Your Migration Involves?

I provide a detailed content audit and migration plan before any work begins. Get a free consultation to discuss your Drupal site's technical requirements.

Get a Free Quote

Migrating Drupal events to WordPress Events Calendar (Tribe Events)

Anthony Lopez-Vito — Fri, 15 Feb 2019 12:04:58 GMT

The The Events Calendar, sometimes known as Tribe Events, is a popular plugin for managing event content in WordPress. It's so popular that it's often the first choice when clients ask me to migrate Drupal event content into WordPress. Here is some sample SQL queries if you need to do something similar.

Sample SQL queries

These are example queries only. Be sure to edit them for your own configuration.

Event date and time

The event date and time is in ISO 8601 without the T character. See how WordPress prefers to format times and dates.


INSERT INTO wp_postmeta (
    post_id,
    meta_key,
    meta_value
)
SELECT
	nid,
    '_EventStartDate',
	REPLACE(field_eventdate_value, 'T', ' ')
FROM drupal_content_field_eventdate;


INSERT INTO wp_postmeta (
     post_id,
     meta_key,
     meta_value
)
SELECT
	post_id,
	'_EventEndDate',
    meta_value
FROM wp_postmeta WHERE meta_key="_EventStartDate";


INSERT INTO wp_postmeta (
     post_id,
     meta_key,
     meta_value
)
SELECT
	post_id,
	'_EventTimezone',
    'UTC+0'
FROM wp_postmeta WHERE meta_key="_EventStartDate";

INSERT INTO wp_postmeta (
     post_id,
     meta_key,
     meta_value
)
SELECT
	post_id,
	'_EventTimezoneAbbr',
    'UTC+0'
FROM wp_postmeta WHERE meta_key="_EventStartDate";


INSERT INTO wp_postmeta (
     post_id,
     meta_key,
     meta_value
)
SELECT
	post_id,
	'_EventOrigin',
    'events-calendar'
FROM wp_postmeta WHERE meta_key="_EventStartDate";

Event details


INSERT INTO wp_postmeta (
    post_id,
    meta_key,
    meta_value
)
SELECT
    nid,
    '_EventURL',
    field_eventorgs_url
FROM drupal_content_field_eventorgs;


INSERT INTO wp_postmeta (
    post_id,
    meta_key,
    meta_value
)
SELECT
    nid,
    '_OrganizerOrganizer',
    field_eventorgs_title
FROM drupal_content_field_eventorgs;

Custom fields

This query will save the filepath of associated files, such as a logo, into a custom field.


INSERT INTO wp_postmeta (
     post_id,
     meta_key,
     meta_value
)
SELECT
    nid,
    'field_eventlogo',
    REPLACE(f.filepath, 'sites/default/files/', '/wp-content/uploads/legacy/')
FROM drupal_content_field_orglogos c
INNER JOIN drupal_files f
ON c.field_orglogos_fid = f.fid;

The Events Calendar meta key cheatsheet

For all the meta keys, take a look at The Events Calendar's WordPress Post Meta Data Cheatsheet.

How to fix a 'Object of class WP_Error could not be converted to string' error in WordPress

Anthony Lopez-Vito — Sun, 16 Sep 2018 11:04:15 GMT

If you see a blank page while trying to log in to your WordPress site, check your web server's error logs. You may get the following error:

stderr: PHP Catchable fatal error:  Object of class WP_Error
could not be converted to string in
/var/[PATH TO YOUR DOCUMENT ROOT]/wp-includes/default-constants.php on line 139

Note that the line number may be different depending on your version of WordPress but the code generating the error is as follows:

function wp_plugin_directory_constants() {

    if ( !defined('WP_CONTENT_URL') )

        define( 'WP_CONTENT_URL', get_option('siteurl') . '/wp-content');

... Do not be tempted to debug by editing the code as it's not the source of the error. Your problem will very likely be that the siteurl option value in your WordPress database does not contain a valid entry. In this case, the error message is telling you that get_option() receives a WP_Error object rather than a string that it's expecting. To fix this:

First check the siteurl option to verify that the value is indeed incorrect. Run the following SQL: SELECT * FROM `wp_options` WHERE option_name = 'siteurl'; You will likely find a serialized array containing a WP_Error object.
Correct the option value by setting it with your domain's URL: UPDATE wp_options SET option_value = '[YOUR URL]' WHERE option_name = 'siteurl';

I'm not sure what overwrites the siteurl option value. Most likely there is a misbehaving plugin installed or malware has infected your installation. Be sure to run a scan on your server.

Why is Drupal the second most dreaded platform?

Anthony Lopez-Vito — Sun, 18 Mar 2018 13:29:15 GMT

According to the Drupal Shell site, Drupal is the second most hated CMS platform. I think this sounds a little harsh. Digging into the source survey on stackoverflow, we find that it's actually listed as the second most dreaded platform. While perhaps more even-handed, I'm still not at all surprised as a large chunk of my business is made up of people migrating from Drupal to WordPress. To be fair, WordPress fans don't have much to cheer. Their platform of choice appears as number three of the Content Management Platforms (CMS) listed in the poll. Still, Drupal had (has!) a loyal following so why does it draw out such a reaction from respondents?

First-mover advantage

Let's take a quick look at the history of the major CMS platforms currently in use. Drupal was, in the first decade of the 2000s, arguably the top CMS for building websites. It had first-mover advantage, having launched as an open source project in 2001 - years before its contemporary competitors. Drupal 4 was released in mid-2002 and started appearing on most developers' radar by around 2004-2005. Its only real competitor was Movable Type which offered simple blogging capability. WordPress was at version 1 in 2004 and was then also more of a blogging tool than a CMS. Magento and Joomla would come around quite a few years later, launching in 2007 and 2009 respectively.

CMS version 1 release timeline
2001	→	Drupal Movable Type
2004	→	WordPress
2007	→	Magento
2009	→	Joomla

A legacy of custom website generators

I remember my first foray into Drupal development in 2003. A freelancer colleague kept raving about how great it was and that I should give it a try. (Incidentally, he subsequently became very active in the Drupal community and ended up having his theme bundled in with core.) At that time, I'd been hand-coding websites and building custom 'site generators'. CMS platforms hadn't taken off so people were coming up with their own solutions for managing site content.

For example, I worked with a top-tier mobile operator in the early 2000s. They asked me to build a web-based knowledge management system that stored content in Microsoft Access and used VBA to publish static HTML. One leading market intelligence agency I worked with at the end of the 1990s had an online customer database. It delivered web pages using Apache modules. We had to code in C++ and query a flat file database to deliver new functionality. That was fun. Imagine having to deal with memory allocation just to output a web page. Just like coding on stone tablets, right?

When PHP appeared on the scene, it rapidly became the preferred way to deliver dynamic web content. PHP simplified web development but people still had to cobble together their own site generators. You'd need to write your own authentication system and all the other things we now take for granted. Developing for the web became easier but you still had to jump through lots of hoops before getting to the interesting work.

It's not difficult to see why, shortly after release, Drupal captured the entire range of the market: hobby sites; small businesses; small and large charities; multi-nationals. They all adopted Drupal because it so quick and easy to deliver complex features.

Features for free

Eventually, my colleague's insistence overcame my resistance to learning new technology. I found that Drupal, in comparison to hand-coding from scratch, was an absolute dream. I could now build feature-rich websites with login functionality, CRUD and custom layouts in maybe one-fifth of the time and cost. Like my colleague, I started raving about Drupal and began recommending it to clients and colleagues.

Drupal was, without any doubt, the most powerful website development platform available. Nothing else in the open-source market could touch it. It was also fun building websites with Drupal. You could get instant gratification by installing and playing with the many available modules. Every developer facing a deadline and budget loves Features for Free when the alternative is hours of coding and debugging. Features for Free is fantastic...unless you have to maintain all those features. More on this later.

Similarly, site owners - who often don't care that much about the technology - loved that their developer could deliver a widgety-thingamajig-feature at a reasonable price. They'd request some functionality and the developer would say, "Yeah, we can do that with Views." "Yeah, there's a module for that, no problem." "Oh, no module for that but we can build one without a huge site overhaul." It was great until, well...

The Drupal can of worms

Well, fast-forward to 2018 and nearly every Drupal site I encounter is a huge can of worms. Those great Features for Free aren't so great when the modules have been abandoned. They're not great when, years after installation, no-one remembers which module controls what and how everything ties together. Sure, documentation and well-commented source code commits are best practice. Perhaps enterprises can afford to maintain a stable of diligent developers. But many sites are cobbled together on a legacy of little to no budget and a revolving door of low-cost developers with varying skills.

Over time, each person adds their own hacks and disappears. No-one willingly runs updates and upgrades because who enjoys having a nervous breakdown? Run an update and risk a WSOD. Spend hours tracking down some obscure, unsupported and misbehaving module that's absolutely crucial to the way this particular site works...for free? No thanks!

Fully-documented sites and well-specified upgrades is the industry ideal. However, real-life tends to go something like this:

Site owner: Hey, remember that site you built for me a couple of years ago? I'd like to...
Developer: mumble...mumble...upgrade to Drupal 5...mumble...[PRICE]....
Site owner: Hmmm, I'm good for now...kthxsbye...

A couple of years later...

Site owner: Hey, this guy built a site for me. I'd like to...
Developer: mumble...mumble...upgrade to Drupal 6...mumble...[PRICE]....
Site owner: [PRICE]???!!! kthxsbye...

A couple of years later...

Site owner: Hey, I have this site...
Developer: Erm...Drupal 7...rebuild the site...
Site owner: What???!!! kthxsbye...

A couple of years later...

Developer: Oh, how many thousands of monies did you say is burning a hole in your pocket? Because, you know, Drupal 8...

Upgrades and backward compatibility

Of course, poorly documented, buggy and abandoned add-ons are all too common in the WordPress world. The big difference is backward compatibility. WordPress has been great with ensuring problem-free updates: you see core, plugin or theme updates available; you click Update Now; a few seconds (or minutes at most) later you're done. You can move on with your day and not give it another thought.

In contrast, updating Drupal can ruin your day. (Or night if you're scheduling the work during off-peak hours.) Drupal updates can go horribly wrong. During the pre-Drupal 8 days, it wasn't unusual to spend hours of site rebuilding after one of the module updates crashed the site. Which module? Well, you'd have some trial-and-error testing on a series of modules, one-by-one, until you find the culprit. Updating Drupal is often a dreadful experience.

Sensible developers test updates on a development server first, then get the site owner to test on staging before rolling out to live. This is best-practice. Everyone should be following this workflow regardless of the platform. Yes, if there's money for it. This effort comes at a price and many, if not the majority, of smaller businesses, not-for-profits and hobby sites just don't have the cash. People have found that WordPress lets them cheat the recommended workflow. If they see updates they just go ahead and do it live because there are rarely any problems.

Core upgrades for major Drupal versions are another level of pain for the site owner. Drupal 6, 7 and 8 are all so different in architecture from previous releases that upgrading essentially means re-building the site from scratch. This is too much to expect for many. No wonder site owners would rather hobble along with their outdated and duct-taped CMS.

The dread

Keeping Drupal up-to-date is expensive for the owner and time-consuming for the developer. Site owners dread to think about the fees. Maintainers dread jumping through hoops just to run simple module updates. Newly hired developers dread what they might find when they peek under the hood.

I started Another Cup of Coffee as a Drupal development shop because it allowed us to offer powerful functionality at a reasonable price. Years later, although I'm no longer in the business of building Drupal sites, I do remember the feeling of dread when time came to tinker with a mature installation. I have every sympathy for those who list Drupal as their second most dreaded platform. It seems that everyone feels The Drupal Dread. Unless of course, they make lots of money from Drupal support.

Photo by Bill Craighead on Unsplash

Related reading:

Ready to Leave Drupal Behind?

Get a Free Quote

Why Automated Migration Tools Fail for Complex Drupal Sites

Aiden — Wed, 11 Oct 2017 09:00:00 GMT

Automated migration tools promise a straightforward path from Drupal to WordPress: install a plugin, point it at your database, and watch your content appear. For a simple blog with standard posts and pages, they might even deliver. However, for sites with custom content types, complex field relationships, e-commerce data, or meaningful SEO requirements, these tools consistently fall short. Here's why.

What Automated Tools Actually Do

The most common tools (FG Drupal to WordPress, CMS2CMS, WordHerd) work by mapping Drupal's core database tables to their WordPress equivalents. They handle:

Basic nodes. Standard Drupal posts and pages migrate as WordPress posts and pages.
Taxonomy terms. Drupal vocabularies map to WordPress categories or tags.
Users. Basic user accounts transfer with login credentials.
Comments. Comment threads attached to nodes migrate to WordPress comments.
Embedded images. Images within content bodies are usually downloaded and re-linked.

For these core data types, automated tools are reasonably effective. The problems start when your Drupal site uses anything beyond the default content model.

Where They Break Down

Custom Content Types and Fields

Drupal's content type system is one of its greatest strengths. It's also the primary reason automated tools fail. A typical business site might have content types for projects, case studies, team members, events, and products, each with dozens of custom fields including entity references, date ranges, address fields, and file attachments.

Automated tools treat all content as either posts or pages. Custom fields are either ignored entirely or dumped into a single text block.

Entity reference fields (the relationships connecting a project to a team member, or an event to a venue) are lost. The data arrives in WordPress, but the structure that makes it meaningful doesn't.

Complex Taxonomy Structures

Drupal supports multiple vocabulary systems with hierarchical terms, custom fields on terms, and cross-references between vocabularies. WordPress offers categories and tags by default, with custom taxonomies available through code or plugins.

Automated tools typically flatten Drupal's taxonomy system into WordPress categories or tags without preserving hierarchy, term relationships, or custom term fields. For sites where taxonomy drives navigation, filtering, or search functionality, this produces a broken information architecture.

Media and File Handling

The most common post-migration complaint is duplicate images. Drupal's media system, particularly in Drupal 7 with modules like Media, File Entity, and IMCE, lets a single image serve dozens of content items through file entity references. Automated tools don't understand that reference structure.

They download and re-upload each instance separately, so a product photo used on ten pages becomes ten copies in the WordPress media library. File metadata, alt text stored at the field level, and image crop configurations are typically lost in the process.

E-commerce Data

Drupal Commerce stores products, orders, customers, and payment records across interconnected entity types with complex relationships. A single order connects to a customer account, multiple product variations, shipping information, payment transactions, and billing addresses.

No automated tool handles Drupal Commerce data. The relationship structure is too complex and too specific to each store's configuration. E-commerce migration always requires custom scripting. There's no shortcut.

URL Structure and SEO

Missing redirects are the most common cause of SEO damage after a platform migration. Drupal's url_alias system allows multiple URL paths per node, including paths with forward slashes and special characters that WordPress can't replicate in its slug field. Automated tools may import content, but they don't generate the 301 redirect map needed to preserve search rankings. For a site with hundreds or thousands of indexed pages, that gap means losing organic traffic that took years to build.

The Real Cost of a Failed Migration

The appeal of automated tools is understandable. They're cheap and fast. However, the cost of fixing a failed automated migration often exceeds the cost of doing it properly in the first place.

Data loss. Custom fields, relationships, and metadata that weren't migrated can't always be recovered. If the original Drupal site has been decommissioned, that data may be gone permanently.
Broken content. Pages that display correctly in Drupal but render as unstructured text blocks in WordPress require manual reconstruction, page by page.
SEO damage. Missing redirects cause immediate ranking drops. The longer the gap between launch and redirect implementation, the harder it is to recover lost positions.
Lost revenue. For e-commerce sites, corrupted product data, broken customer accounts, or lost order history directly impacts business operations.
Team time. Someone has to fix all of this. The time your team spends cleaning up automated migration output is time not spent on business activities.

When Custom Scripting Is Necessary

If any of the following apply to your site, automated tools won't produce acceptable results:

Custom content types. Any content type beyond basic posts and pages with custom field configurations.
E-commerce. Drupal Commerce or Ubercart stores of any size.
Complex taxonomy. Multiple vocabularies, hierarchical terms, or terms with custom fields.
Large media libraries. Thousands of files with structured metadata and multiple references.
SEO-critical sites. Any site where organic search drives meaningful business value.
User accounts. Sites with authenticated user features, member areas, or role-based access.

Custom scripting means writing migration code that understands your specific data model: the relationships between content types, the custom field structures, and the business logic that automated tools don't know about. It's more work upfront, but the output is a clean, complete WordPress site rather than a partially migrated dataset that needs weeks of manual cleanup.

When Automated Tools Might Work

To be fair, automated tools have their place. They can be a reasonable option if:

Your site is simple. Standard blog posts, basic pages, and default Drupal fields only.
No custom content types. Everything uses Drupal's built-in Article and Basic Page types.
SEO isn't critical. You're not reliant on organic search traffic and can absorb a temporary ranking drop.
No e-commerce. No product catalogues, order histories, or customer accounts to migrate.
Small media library. A manageable number of images that can be manually reviewed after migration.

If this describes your site, an automated tool followed by manual cleanup may be cost-effective. For everything else, custom migration is the reliable path.

Making the Right Choice

The decision between automated tools and custom migration comes down to risk tolerance. If the data is replaceable and the SEO stakes are low, an automated tool is a reasonable gamble. If the data is business-critical, the relationships between content items matter, or your search rankings drive revenue, custom scripting is the only approach that delivers predictable results.

I assess every project individually and recommend the approach that fits the site's actual complexity. For simple sites, I'll tell you an automated tool will do the job. For complex ones, I'll explain exactly what custom scripting involves and why it's worth the investment.

Related reading:

Not Sure If Your Site Needs Custom Migration?

Send me your site URL and I'll give you an honest assessment: whether automated tools will work for your situation or whether custom scripting is the way to go. No obligation, no sales pitch.

Get a Free Quote

Post-migration troubleshooting: Gateway timeout when enabling plugins

Anthony Lopez-Vito — Mon, 05 Jun 2017 09:35:07 GMT

Here's one that caught me out on a recent Drupal to WordPress migration. As is common with my projects, there were three parties involved: the client, an external development team and myself. The WordPress site was first built on the development team's server, after which it was migrated to my local environment. When everything was ready for beta testing, we moved the site over to the client's staging server on a newly activated account over at Kinsta. Eventually, we'd move it over to a live server, also hosted on Kinsta.

After some initial tests on staging, I found that deactivating and reactivating plugins would cause the site to hang and show a '504 Gateway Time-out' error. This happened when re-enabling some but not all plugins.

I initially suspected some misconfiguration at the hosting end because there were some hitches with the newly create account. At the outset, the account's server had an issue which Kinsta support needed to fix. For convenience, we'd also made use of Kinsta's free site migration service. This is where they'll migrate an existing WordPress site into their environment. Though it would have been easy enough for me to do, we thought to give it a try. In hindsight, this was a bit of a mistake. The site migration service itself was fine but it did end up causing some confusion. First, a miscommunication in the migration request caused them to create a temporary domain we didn't want. They helpfully solved this by giving us a second temporary domain. However, they'd also upgraded everything to PHP 7 in the process. All of these issues were possible suspects for the time-out error but turned out to be red-herrings.

It took some time to pinpoint the cause behind the Gateway Time-out error. I do have to say that Kinsta support were very responsive throughout the troubleshooting process. They eventually put a senior engineer on the case who found the problem. It turned out the problem wasn't to do with Kinsta at all. There was a leftover setting from the original development team's server. It was a valid format so didn't cause an issue on either my local server or my staging server. However, it apparently can cause issues with plugins and did on the Kinsta environment.

What was the setting? The WordPress upload path directory was set to the development team's server path e.g. /home/dev/public_html/sitename. Throughout the migration, I'd been doing a database search-and-replace looking for their development domain. Somehow, as the site moved from different servers, that server path string remained in the database, only to cause a problem when the site landed in the destination server on Kinsta.

I'm not sure if there would have been any way to have caught this problem earlier. It's one of those obscure errors that are easy to overlook and take time to resolve. There's also no practical way to do a database search-and-replace for every imaginable string. I'll have to rack this one up to experience.

How to change the WordPress table prefix prior to a migration

Anthony Lopez-Vito — Thu, 16 Mar 2017 13:12:02 GMT

When working on a Drupal to WordPress migration project, I like to migrate into a set of intermediary WordPress tables that live in the Drupal database. These are working tables where I can run various scripts to process and clean up the content before exporting to a working WordPress installation. It's not necessary to do this but I find it convenient to run scripts on the same database rather than deal with two separate database connections.

Note that some people suggest renaming the table prefixes to improve security. My use of the table prefixes is simply to create temporary containers for the migration. While non-standard prefixes might help prevent 'script kiddie' attacks, I find it isn't worth the disadvantages that come with this sort of security through obscurity (or more precisely, security through minority) approach. Here are two articles give a deeper explanation of topic:

wordfence.com: WordPress Table Prefix: Changing It Does Nothing to Improve Security
wpkrauts.com: The database table prefix is not a security feature

SQL queries to change the WordPress table prefixes

You can start with a freshly installed WordPress database. Dumping this and importing to your Drupal migration database will give you all the tables with the correct WordPress schema. I use the acc_ prefix but you can use whatever you want.

Rename the tables with these queries:

RENAME table `wp_commentmeta` TO `acc_commentmeta`;
RENAME table `wp_comments` TO `acc_comments`;
RENAME table `wp_links` TO `acc_links`;
RENAME table `wp_options` TO `acc_options`;
RENAME table `wp_postmeta` TO `acc_postmeta`;
RENAME table `wp_posts` TO `acc_posts`;
RENAME table `wp_terms` TO `acc_terms`;
RENAME table `wp_termmeta` TO `acc_termmeta`;
RENAME table `wp_term_relationships` TO `acc_term_relationships`;
RENAME table `wp_term_taxonomy` TO `acc_term_taxonomy`;
RENAME table `wp_usermeta` TO `acc_usermeta`;
RENAME table `wp_users` TO `acc_users`;

Testing the migration results

If you need to point a WordPress installation to these tables for testing, you'll need to do two things:

Update the $table_prefix setting in the wp-options.php file
Update the options and usermeta tables

Updating the $table_prefix setting in the wp-options.php file is straightforward. Open the file and edit the line:

$table_prefix  = 'acc_';

In WordPress, prefixes are saved as entries in the options and usermeta table. Check for entries containing the prefix:

SELECT * FROM `acc_options` WHERE `option_name` LIKE '%wp_%';
SELECT * FROM `acc_usermeta` WHERE `meta_key` LIKE '%wp_%';

When you have all the entries, update them with the new prefix. The query will probably look something like this:

UPDATE `acc_options` SET `option_name` = 'acc_user_roles' WHERE `option_name` = 'wp_user_roles';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_capabilities' WHERE `meta_key` = 'wp_capabilities';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_user_level' WHERE `meta_key` = 'wp_user_level';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_user-settings-time' WHERE `meta_key` = 'wp_user-settings-time';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_user-settings' WHERE `meta_key` = 'wp_user-settings';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_dashboard_quick_press_last_post_id' WHERE `meta_key` = 'wp_dashboard_quick_press_last_post_id';

A word of warning: it's easy to forget to change the prefixes back to match the final WordPress installation. If you do, the WordPress user accounts will have problems, such as the Dashboard controls not being visible after logging in. Because of this, I tend to have a separate testing installation that gets an import of the working tables.

Cover photo by Gavin Allanwood on Unsplash

Need Help With Your Drupal to WordPress Migration?

I specialise in complex Drupal to WordPress migrations, including database preparation, table prefix management, and post-migration testing. Get a free, no-obligation consultation.

Get a Free Quote

Complex CMS Migration Service - Migrate Content

Platform Migrations Aren't Website Design Projects

How the Mismatch Happens

What's Actually Underneath

Where the Gap Opens Up

Business Analysis Is Boring. It's Also the Most Important Part.

Going Live Is Not "Take the Site Down for a Bit"

Coordinating the Moving Parts

Why It Keeps Happening

Before You Start: What to Check

For business owners

For agencies

What It Looks Like When It Works

Get Someone in the Room on Day One

Common Questions

You may also like

How We Migrate: The Technical Process Behind a Migration

Why Automated Migration Tools Fail for Complex Sites

Preserving Your SEO During a Migration

Footnotes

Migrating Drupal Commerce to WooCommerce: What You Need to Know

Why Automated Tools Fail for E-commerce

What Needs to Migrate

Product Data

Order History

Customer Data

The Migration Process for E-commerce

1. Commerce Audit

2. WooCommerce Architecture

3. Custom Migration Scripts

4. Payment Gateway Transition

5. Zero-Downtime Launch

Common Pitfalls

Timeline and Investment

Planning a Drupal Commerce to WooCommerce Migration?

Preserving Your SEO During a Drupal to WordPress Migration

Why Migration Puts Your SEO at Risk

URL Structure: The Critical Difference

How Drupal Handles URLs

How WordPress Handles URLs

What This Means for Your Migration

Building Your Redirect Map

Meta Data Migration

Taxonomy Pages and Listing Pages

What Gets Preserved Automatically

Common SEO Pitfalls

When to Invest in SEO Preservation

Concerned About Losing Your Search Rankings?

Drupal 7 End of Life: Your Migration Options in 2025

What Drupal 7 End of Life Actually Means

Three Realistic Options in 2025

Option 1: Extended Support (Short-Term Fix)

Option 2: Upgrade to Drupal 10/11

Option 3: Migrate to WordPress

What a Professional Migration Looks Like

The Cost of Waiting

Need Help With Your Drupal 7 Migration?

Drupal 7 End of Life: Why WordPress is the Best Migration Option for Lower Maintenance Sites

Final Deadline Announced After Multiple Extensions

What Happens If You Stay on Drupal 7?

Why Choose WordPress Over Upgrading Drupal?

Is it Worth Upgrading Drupal?

Real-World Success Stories

The Migration Process

The Process:

Why WordPress is the Smarter Choice Today

Let's Talk

Drupal to WordPress migration service

Drupal 7 End of Life Frequently Asked Questions

Footnotes

The Benefits of migrating from Drupal to WordPress: Key Insights from WP Engine's Latest Webinar

Table of Contents

Watch the Webinar

Speakers

The Current CMS Landscape

Drupal's Declining Position

WordPress's Market Dominance

Key Migration Drivers

Ease of Use and Training

Cost Considerations

4. Create Your `.env` File

6. Create Your `docker-compose.yml` File