Any successful project requires careful planning and a Drupal to WordPress migration is no exception. It can be tempting to head straight to setting up WordPress, trying out new themes and experimenting with plugins. Website owners and administrators know their content is important but it can sometimes become an afterthought in the excitement to play with the new content management system. After all, you can use the Drupal site as the template and simply export over all the content over, right? For some site owners that’s all there is to it. However, you should be aware that site migrations can have hidden pitfalls that turn an apparently simple project into one fraught with complications.

The key to avoiding problems is to plan your Drupal to WordPress migration before you even touch your server. Whether you migrate the site yourself or hire me to help you, this guide will give you a head start with your planning. Keep in mind that general project planning principles apply but there are already many resources on this topic. I will focus on the areas important specifically for a migration from Drupal to WordPress.

Step 1: Consider why you are migrating to WordPress

There are many content management systems available and I’m going to assume you have already thought carefully about why you’ve chosen WordPress. For the sake of completeness, I’ll include this step because your reasons will determine whether or not the migration project will be a success.

In case you need a reminder about the merits of either CMS, here are a few Drupal vs WordPress posts:

If you haven’t already put together a migration requirements document, go ahead and create one now. I go through this migration requirements checklist with my own clients and it might help you too.

Step 2: Decide on your approach to building the WordPress theme

The WordPress theme, just like in Drupal, is what handles how your site looks. A migration to a new CMS often goes hand-in-hand with redesigning the site. I’ve put this step early on because a site redesign could be an entirely separate project. You might want to run in parallel with the migration or it could be something you’d want to start before kicking off the content migration.

Step 3: Be aware of any SEO impact when migrating to WordPress

WordPress has an excellent reputation for being SEO-friendly but beware of taking this for granted. The Search Engine Journal post linked in step two should have given you a sobering outlook on how making changes to your site will affect your SEO. In my experience, preserving SEO takes a large part of the time and budget of many migration projects. Sometimes the cost will outweigh any benefit of trying to preserve the SEO customisations on your Drupal installation. This is often a commercial rather than technical decision. If you run a site that relies on search traffic, I recommend that you hire an SEO consultant to advise you. In fact, I will often work with and take direction from a client’s SEO consultant during a typical Drupal to WordPress migration project.

Step 4: Gather as much information as you can about your Drupal installation

Knowing as much as possible about your Drupal installation will help me come up with a more precise estimate for your migration project. If you’re doing the migration in-house, it will help you plan how much time to set aside and which team-members need to be involved.

Site owners who built and manage the site will likely have records of some information but not necessarily all the details of how Drupal is configured. Site owners also come to me with a site built by a third-party. They have working knowledge on how to manage it and add content but not anything else. I can help you discover the information needed for the migration if you are in this position but you can save budget by doing some investigation yourself. Use my Drupal to WordPress migration worksheet as a guide.

The formal name for this is a site audit but essentially you need to find out about two areas:

How to access your server

What kind of content you have

Server audit

You’ll need your FTP server details to access your Drupal installation, media files and to upload the WordPress package. When running a migration, I like to download a full working version of the Drupal site on my local development server. This isn’t necessary but can be useful for figuring out formatting problems that crop after content migration. For example, you may find missing bits of text on WordPress and some investigation on the Drupal installation will show the text will be from a custom field or block.

The database server is necessary for exporting your Drupal database and setting up WordPress when the migration is complete. Some hosting providers offer access through a cPanel interface, a separate phpMyAdmin link or by command line. Gather all these details ahead of time will help get your project started quickly.

Content audit

The content audit helps you discover what type of Drupal content do you have. Drupal, like most other content management systems, keeps content in two places:

The database

On the server filesystem

Types of content include:

Nodes

Views

Blocks

Panes

Taxonomies

Static HTML files

Embedded media like videos, images and audio

File attachments

User profile information

Content metadata

You may be surprised where the different bits of content that make up your site ends up being stored. A content audit will avoid unnecessary complications with trying to hunt down bits of data mid-migration. My Drupal content audit checklist should get you started.

Step 5: Write a Drupal to WordPress migration mapping document

The migration mapping document will help both with quoting for project as well as keeping track of everything that needs to be done during the migration. It gives everyone involved a framework to work on.

I know, this sounds like a mouthful and so very tedious. Truth be told, few people find writing specification documents fun but it is a necessary step if you want to avoid unexpected costs and delays. The more detailed you are, the fewer surprises there will be for everyone during the actual migration. Your investigations during step 4 will lay the groundwork for the migration specification.

I will write another post on how to write migration mapping document but the document doesn’t have to very formal. All it needs to do is clearly convey the state of your Drupal site and what you’d like migrated to WordPress.

Ready for your migration project

Running through these steps will put you in a good position for your migration from Drupal to WordPress. Admittedly, there have been projects where I or the site owner didn’t bother to do any detailed planning and we were able to get by. Usually, this was because of limited budget or a rush to launch the new WordPress site. However, the projects where we took some time out to plan ahead were always closer to the estimated budget and posed fewer surprises.

A little plug to keep the lights running. If you think all of this work is too much trouble, please consider hiring me for your Drupal to WordPress migration project.

The minimum requirement is some sort of access to your Drupal database. For security, we’d prefer not have access to your live servers so a compressed MySQL database dump file of your Drupal site is ideal. If you have no-one to create the database dump file, we can create one on your behalf by logging in to your MySQL control panel or database server.

In the cases of large databases, we’d need to work directly on your server since transferring dump files of many gigabytes is impractical. A good practice would then be to clone the database and give us a separate login to the server. That way we won’t have to touch your live server and data.

An admin login to the Drupal control panel on a clone of your site would be useful for fine-tuning and debugging. This is normally not necessary for the first test export.

We generally take care of setting up the entire development environment on our servers. This includes creating an empty WordPress site for displaying results and for some complex migrations, a clone of your Drupal site for analysis. If you have limited budget, you can save on fees by providing us with the development environment set up and ready to use.

Since there are so many variations between Drupal installations, it’s not practical to give reliable cost and time estimates from the outset.

We really only start to understand the scope of the work after running the first few exports. Furthermore, the modules installed during the life of your Drupal site may have altered the structure of the database. This affects how cleanly we can run the migration and how many adjustments will be necessary.

Nevertheless, you remain the driver of how much work we put in. Some site owners request lots of adjustments while others are happy to have just a few aspects of their old site migrated. The biggest factor affecting the budget is therefore the amount of communication needed with regard to the adjustments.

For the bottom-end migration, all we need to do is run through our migration script. You take care of everything else, including setting up the development server. We charge more if you have very rigid requirements which involve writing lots of code to automate tasks.

The whole migration process is very much an iterative process of fine tuning until you’re satisfied with the end result. We call each iteration a ‘pass’ because we pass through the database with our migration script repeatedly, making slight adjustments as we gather more information.

Since there are so many variations between Drupal installations, we really only start to understand the scope of the work after running the first few exports. Our process starts off as follows:

We run a test export and show you the result using a standard WordPress installation;

You let us know how much more fine-tuning is needed.

So for example, we’d run through the first pass and ask you to take a look at the content. You let us know if you discover any issues, like missing posts or meta information (e.g. tags, authors and dates). We then adjust the migration script and run another pass. This repetition continues until you decide it’s good enough.

Why would there be missing information? The number and type of modules you’ve installed during the life of your Drupal site could have effected the structure of the database. This then affects how cleanly we can run each pass of the migration. For example, one client installed a module that ended up silently duplicating certain tags. We had to write custom code to remove duplicates and merge the associated posts. All of this took a great deal of time.

There’s rarely a ‘perfect’ migration due to the differences between the how Drupal and WordPress store the data for your site. Often, ‘good enough’ is a compromise between your budget and how close the WordPress version is compared to the original site. It’s not always possible to get an exact copy in WordPress, especially for more complex Drupal installations.

In fact, it’s usually too expensive to be overly specific about what gets migrated over because we’d write code and debug custom rules. We generally recommend bulk migration of only the aspects that would be tedious to do manually, then getting a human editor to ‘eyeball’ the content to make very specific changes using the WordPress user interface. It’s a boring job for the content editor but it tends to be cheaper and more accurate way of polishing off the migration.

There are many sites offering free and royalty-free images. A web search for ‘royalty free images’ should bring up quite a few high quality sites. We’ve had good feedback about images from the following:

There really isn’t a standard list because each site tends to have slightly different features. Generally, though, there are three main areas that should be tested:

(A) Technical (do the features work correctly?)
(B) Usability (is the site easy to use?)
(C) Accessibility (can visitors access the site’s content without too much trouble?)

Here’s a common list of technical things to check that would apply to most of our clients’ site:

Does the site display on different browsers and operating systems? (Which browsers depend on your target market but usually they’d be Internet Explorer 7, 8 & 9, Firefox 11 & 12, Safari 5, Chrome 18. Operating systems for the general market would be Windows and Mac. We don’t usually consider mobile access unless it’s a feature that clients specifically request.)

Are there any broken links?

Are all the pages formatted so that all content is visible?

Does the search facility turn up the correct results?

Can you click through to the content images and do they expand and close to return you to the article?

As you can see, this is all pretty basic stuff because most of our site’s features aren’t too complex.

Because of this, I suggest that your user testing should mostly be focusing on non-technical aspects like (B) and (C). However, because the bulk of these areas are subjective, it’s difficult to come up with an actual list. Therefore, I would suggest having free form comment boxes for people to leave their feedback.

Another thing to note is that the UK and EU have legislation covering web accessibility. You can find out more about this via the following links:

http://www.web-accessibility.co.uk/legal.asp

http://www.w3.org/WAI/Policy/#UK

http://www.w3.org/WAI/Policy/#EU

Unfortunately, this topic is quite a complex and time consuming area and most companies and web developers know little about the subject. There are also doubts about how these laws can actually be enforced. Furthermore, there are no specific definitions on what exact standards must be met within the UK. Thus it is my experience that many web owners and developers simply ignore the issue.

My policy is that we use web-standards compliant technologies where possible. This resolves most accessibility issues within reason for the amount invested in development. However, if a client wants to meet specific standards compliance, we do this under our standard hourly rate as an added service.

Ultimately, this is a business decision to be made on the client end whether this should be a focus.

Edit 22 April 2013: It seems that the businesslink.gov.uk website has now been replaced by gov.uk and the above links no longer work. However, the sample privacy policy does still seem to be online for the time being at this link. (Microsoft .doc download, 28KB)

Projects tend to vary for each client but the process goes as follows:

I’ll send you an invoice for a 50% down-payment to cover for the start-up costs.

You’ll receive log-in details to our project collaboration site. This will show some initial project time-scales and check-lists of what needs to be done.

We’ll schedule your work as soon as we receive your down-payment remittance.

Timescales

From experience with many other projects, I now generally do not specify timescales for the stages in the initial work agreement or invoice. There are several reasons for this:

For the majority of projects, the original timescales end up changing part way into the work. The reasons vary, such as a change of focus, new ideas for features and as is often the case with start-ups, an evolution in the business priorities.

The stages themselves are not fixed and sometimes we end up running them concurrently, starting early or delaying them.

Instead, we work towards some broad milestones that are set by our clients. The milestones are set on our project collaboration site and are adjusted depending on how the project evolves.

Testing

Testing is another area where we differ slightly from some other web companies.

In my opinion, the best people to test the site are the clients themselves; you know better than anyone else how you expect things to work. We’re then guided by your observations.

This process helps keep our fee low because I don’t need to hire dedicated testers or get expensive programmers to do the job. It also skips the time intensive (and expensive) test specification documentation what would be necessary if we were to perform the tests thoroughly.

Testing is therefore more of a collaborative process with you.

For us, testing starts very early on in the project. The usual procedure many web companies follow is to give access to the site towards the end of the development process, only when things are ‘ready’ for the client to view.

I believe that it helps to let you loose on it early on because it gives you a realistic expectation of how things are going all the way through our work together. It also gives you a chance to ask questions and steer things in the right direction while we develop the site.

Testing period

Because of the above, I find that specifying a testing period in the contract usually isn’t very flexible.

It’s also quite difficult to stick to the period specified. For many clients, the website, while important, isn’t the only thing they must deal with in their business. In my experience, things nearly always come up that prevents them from dealing with the task during the allocated time.

For example, let’s take a client’s suggestion of a testing period of two days after delivery. I find what happens in practical terms is that if I deliver, say, on Monday, the client would have a meeting on the Tuesday, then a series of calls for Wednesday and so on. Thus the testing period expired but the client was still unable to even look at the site.

Again, this is another reason why we actually start the testing process near the beginning of the project.

Of course, if you prefer to have the period specified in the contract, we can do our best to meet it but with the caveat that things might not turn out that way.

Quite a few clients have asked if they can run an email marketing campaign through our servers using an email program like Microsoft Outlook. The main thing to note is that email accounts provided by our hosting company, Rackspace, are not really to be used for sending out bulk emails. Although it is technically possible this method is not recommended for several reasons:

You may breach Rackspace’s terms of service

It’s more error-prone and therefore the results are unreliable.

There is no way to gather metrics such as view and click-through statistics.

There is a risk of getting your domain blacklisted as a spam sender by ISPs. Once you’re on the blacklists, some or all of your email accounts will keep ending up in the recipient’s spam filters. It may be very difficult to get off the blacklists.

However, many of our clients are small and micro-business who send out nowhere near the levels of bulk mail as many larger corporations. I’ve therefore contacted Rackspace to ask what are the allowable limits under their Rackspace Cloud service. Based on their reply, you should be safe if you:

Send no more than 250 messages per 20 min

Send no more than 5,000 messages per day

Include an unsubscribe link in the messages (and act on the request)

Send only to people who’ve given you permission to contact them about this

Nevertheless, I recommend that you a dedicated bulk emailing service to send to your distribution lists. The catch is that there’s a fee and the legitimate ones are very strict with how you’ve gathered the email addresses. (They won’t allow you to send to people who haven’t given you their permission.) However, the messages are more professional and you’ll be able to track statistics such as the number of emails that have been opened, unsubscribed or bounced.

We use such a system and if you’re interested, I’ll be happy to put together a quotation for you. As a rough idea, our profile of clients tend to average approximately £10 per campaign to use the system.

If your application is going to be sending out single messages (or less than 25 messages at a time), we highly suggest using SMTP. SMTP is a better option for sending out small amounts of mail. If you have questions on configuring your application to use SMTP, please visit with a member of our support team.
On the other hand, you may need to use our mail relays if your application will be sending out messages to a larger mailing list. If that’s the case, please review the following rules for sending messages through our mail relays:
1. Your message must have a working unsubscribe link, which must be demonstrated to us upon request.
2. The message must have a valid Return Path. This means the message must have a valid from address listed in the message.
3. The message of the email can only refer to the domain the message is being sent from. This means “DomainA.com” cannot send messages for “DomainB.com.”
4. You must obtain Rackspace Site’s advance approval for any bulk or commercial e-mail, which will not be given unless you are able to demonstrate, at a minimum, that your intended recipients have given their consent to receive e-mail via some affirmative means, such as an opt-in procedure, your procedures for soliciting consent include reasonable means to ensure that the person giving consent is the owner of the e-mail address for which the consent is given, you retain evidence of the recipient’s consent in a form that may be promptly produced on request, and you honor the recipient’s and Rackspace Site’s requests to produce consent evidence within 72 hours of receipt of the request.
5. We do not allow bulk or commercial e-mail being sent to more than five-thousand (5,000) users per day at a rate of 250 messages every 20 minutes.
6. Rackspace Sites may test and otherwise monitor your compliance with its requirements, including requesting opt-in information from a random sample of your list at any time.

Getting a website set up can be quite easy but at a minimum, there are three things you’ll need:

1. The domain name

This is makes up the website address and requires registration and yearly renewals. It’s like the online equivalent of registering your company. For a web hyperlink, the domain is to the right of the ‘http://www’ and before the first backslash; for an email address, it’s after the ‘@’ symbol.

If you are a client, just send me the domain you’d like to register and we’ll take care of the details for you.

To register a domain name yourself, find a registrar and follow their registration procedure. There are lots of companies that offer registration services and a web search should bring up a list of popular providers. Make sure that the registration is under your name as some try to lock you in to their service by registering the domain under their own company name.

Some registrars offer extras, like privacy protection, at a price whereas the extras might be included free by other providers. Many also offer email and web hosting which is often automatically included during their registration process. We will provide you with hosting under a maintenance agreement so pay close attention to the purchase itemisation if you only need to register the domain.

Note that you might have to get creative with the name. If the one you want is already registered, you may have to think up different variations until you find something that’s available. Purchasing a domain from an existing owner tends to be quite expensive.

Once you’ve registered your domain, just send me the login details so that I can do the rest of the setup.

2. The website itself

This is the actual design and text visitors see when they visit your site. In the past, developers used to code each page manually. Every time you wanted to change the text on a page, you’d need to ask the developer to recode it.

These days, adding and updating websites are much simpler through the use of Content Management System (CMS) software. The CMS runs on the server and allows you to make day-to-day changes, like updating text and photos, without having to hire a web developer. Your website can be easily managed by a non-technical office administrator or secretary.

For simple sites, I usually suggest that we use the WordPress as this will make it easy for you to add and edit content. Drupal can be used for sites requiring more complex functionality.

Settling on a design is the trickiest part of setting up a website and normally takes a long time. For those who want to get the site up and running soon, it’s best to use a pre-made template. These can be downloaded online for free or quite cheap (about USD30-USD70).

Some people don’t like using a template because it’s not original or unique. While I think this is the best route when starting up a new venture that has limited budget, we’ll be very happy to work on a custom design from the very start. If you’re interested in this, please contact me for more information.

3. Hosting

Websites need to run on powerful computers, called servers, that are permanently connected to the internet. It’s quite expensive to run a business-grade server yourself so hosting companies offer a service where you ‘rent’ space on their computers. They take care of the management so all you need do is provide the website files. (This is similar in concept to renting space in a serviced office.)

We provide hosting free of charge for clients on a maintenance agreement with us.