Now powering over 17% of the Web, WordPress is increasingly becoming the content management system (CMS) of choice for the average user. But what about websites built with an outdated CMS or without a CMS at all? Does moving to WordPress mean starting over and losing all the time, energy and money put into the current website? Nope!
Migrating a website (including the design) over to WordPress is actually easier than you might think. In this guide, we'll outline the migration process and work through the steps with a sample project. We'll also cover some of the challenges you might encounter and review the solutions.
About This Guide
Before we get to work, let's establish some context. First, this guide was written primarily with beginners in mind and will be most helpful for basic websites. Some of you will likely encounter advanced aspects of WordPress migration, but they are beyond the scope of this guide. If you're tackling an advanced migration and get stuck, feel free to share your difficulty in the comments below.
Objectives
The objective of this guide is to help you with the following:
- Plan an effective migration to WordPress.
- Walk through the technical steps involved in migrating.
- Get ideas and resources to solve common migration challenges.
Assumptions
I assume you have basic familiarity with WordPress. Previous development experience with WordPress would be helpful, but not necessary. I also assume you have an existing website and design that you want to migrate to WordPress.
Basic Steps
Here are the basic steps that I recommend you follow for a typical WordPress migration:
- Evaluate website.
Work carefully through the pages on your existing website, identifying all of the types of content (standard pages, photo galleries, resource pages, etc.) and noting any areas that need special attention. - Set up environment.
Set up WordPress and get ready to import. - Import content.
Bring over and organize your content, whether via an importing tool, manual entry (for a small amount, when no tool is available) or a custom importing process. - Migrate design.
Incorporate your existing design into a custom WordPress theme. - Review website, go live.
Carefully review the import, making adjustments where needed, set up any URL redirects, and then go live.
With this outline in mind, let's work through each step in detail.
Start With A Plan
The key to a successful migration is to carefully evaluate your current website. You need to figure out how to import and structure the content in WordPress before carrying over the design.
While the principles are the same across migration projects, the details often vary. So, below are two lists of questions to ask as you work out a plan.
Imported Content
- How much content needs to be imported (number of pages, number of images, etc.)?
- Is the volume low enough to be imported manually, or do you need a tool?
- If you need a tool, does one already exist?
- Can the content be categorized into the standard "posts" and "pages," or does it call for custom post types?
- Does extra content need to be stored for certain pages (custom fields, taxonomies, etc.)?
- Will the URL structure change? If so, will the old URLs need to be redirected?
Existing Functionality
- Does the website integrate any third-party services (data collection, reservations, etc.)?
- Do any forms need to be migrated (contact forms, application forms, etc.)?
- Is access to any content restricted (such as members-only content)?
- Does the website sell products (digital or physical)?
- Do any administrative tools need to be carried over (such as custom CMS functionality)?
A Working Example
My brother, Joshua Wold, has volunteered a website to serve as an example; it's for a side project of his in which he sells posters and postcards of a Vegan Food Pyramid. He built the website in plain HTML, with some basic PHP includes for the header and footer. Below is a screencast of me evaluating the website to give you a sense of how the process will work. Enjoy!
Set Up WordPress
Before importing the content, we need to get WordPress ready to go. If you're just experimenting or if you prefer offline development, start with a local installation of WordPress. Otherwise, the next step is to install WordPress with your current hosting provider; or you could use the migration process as a great opportunity to move to a new host.
Once WordPress is up and running, you're ready for action!
For our example, we've installed WordPress with the same host, setting it up in a /wp directory for the duration of the migration process.
Settings and Plugins
With WordPress installed, we'll make a few minor adjustments:
- Update permalinks.
Go to Settings → Permalinks to make changes. In most cases, I'll switch to "postname"-style permalinks. - Update users.
I create an admin-level account for myself and any admin or editor accounts that are needed for clients and collaborators. I also remove the default "admin" user name if it exists (a basic but wise step for WordPress security).
Depending on the needs of the project, we might have to preinstall plugins. Here are the major categories of plugins:
- Form management
Migrating a form "as is" is usually a mess; simply recreating it using a forms plugin is usually easier. My current favorite is Gravity Forms ($39+ per license). Other options are Formidable (with free and pro versions) and Contact Form 7 (entirely free). - SEO management
Search engine optimization (SEO) is a touchy subject. My philosophy is to build content for people, not for search engines. That being said, there is a common-sense approach to SEO that is solidly supported by the WordPress plugin ecosystem. And if your old website includes custom meta descriptions, giving them a new home during the importing process is important. I recommend WordPress SEO (free). - Multiple languages
If your old website supports multiple languages, WordPress has you covered. My plugin of choice is WPML ($79 per license, free for non-profits). Another option is qTranslate (free). - Security
WordPress security is a topic near and dear to me. The increasing popularity of WordPress has made it a target for security attacks. WordPress itself is rarely the problem; a poorly secured hosting environment or an outdated or poorly developed plugin usually is. I use managed WordPress hosting for the majority of my projects, which offers a good foundation for solid WordPress security. Options include WPEngine, ZippyKid, Pagely and Synthesis. In addition to managed hosting (and especially if you opt for a non-managed host), consider installing a security plugin, such as Better WP Security (free) or Wordfence (also free). Last but not least, review the "Hardening WordPress" guide in the Codex. - Backups
If you opt for managed hosting, backups are usually included (make sure, though). If you're managing backups yourself or you want an extra layer of data protection, great options are available, including VaultPress ($15+ a month), CodeGuard ($5+ a month), BackupBuddy ($75+ per license) and BackWPup (free).
Import Content
With WordPress up and running, it's time to bring over all of your content.
If your old website has a CMS, an importing tool might be available. Start by viewing the list of content-importing scripts in the Codex. If there's a match, great! Follow the instructions and get to work. If all goes well, you'll have migrated the content over without any trouble.
If your old CMS is not in the list or you don't have a CMS at all and you've got fewer than 100 pages, then manual migration is probably the way to go. Copy and paste the contents, noting the old URLs as you go (tracking the migration in a spreadsheet is a good idea).
If you've got a custom CMS or a database of records without an importing tool and a high volume of content, then you might want to bring in a specialist to move the content over before continuing. The higher the volume of content, the higher the chance of human error and the more important automating it becomes.
For our project, I've migrated the content manually and replaced the existing navigation with a WordPress menu. You can watch the process in this next screencast:
Bring Over The Design
With our content in WordPress, it's time to bring over the design. Incidentally, if you're considering a new design, then now is a great time to look at the many excellent WordPress themes out there, both in the official repository and in third-party marketplaces such as ThemeForest and Creative Market. For our purpose, I'll assume that you're happy with your design.
Evaluating A Design
Evaluate the source code of a prospective design as best you can before tackling the migration. If the code is table-based or more complex than you're comfortable with, then migrating the design might not be worth the effort. While anything is possible (I've migrated some complex table-based designs in my time), not everything is practical.
Working With Source Code
In my experience, the easiest way to migrate is to work directly with the source code in the browser. While having access to the original hosting environment can be helpful (especially when working with a lot of images and downloadable files), the ways that websites are built vary so widely that you'll often have to reverse-engineer the original architecture in order to derive anything useful.
Going directly to the source code in your browser of choice will save a lot of time and, barring any important "behind the scenes" functionality, give you everything you need. Google Chrome is currently my browser of choice, and I've pulled our source-code samples directly from the browser. (In Chrome, go to Menu → Tools → View Source, or just right-click to bring up the contextual menu.)
Create A Custom Theme
If you're new to them, learn about using themes in the Codex. For the migration process, you can either build a new WordPress theme from the ground up or modify an existing theme to meet your needs. I recommend the latter.
Most of my migration projects have started with the latest version of WordPress' default theme (currently Twenty Twelve). Recently, I stripped down the default theme to create my own migration starter theme, which I'll use in our example and which you're welcome to use yourself. (Feel free to suggest improvements!) Let's get to work.
Download a copy (ZIP) of the migration starter theme or follow along in your own theme of choice as we work through the relevant theme files.
1. Style Sheet
Our first step is to bring over the styles from the old website. In most cases, this is as simple as searching the source code for references to .css and then copying and pasting the contents from those style sheet(s) into our own style.css. Let's get to it.
- Open up
style.css. - Replace the details of the theme ("Name," "URI," "Description," etc.) with your own.
- Paste in the styles from the old website.
A Note About Images
As you migrate the style sheet(s), search for and update any references to images. In general, I like to keep all images in an /images/ folder within the theme's directory. More often than not, changing the locations of images referenced in the original CSS is necessary, and I make sure to update all references in the style sheet and templates accordingly.
2. Header
The next step is to create the header for our new theme. Our objective here is to merge the structure of the current code base with WordPress' templates. Here's what we're going to do:
- Replicate the HTML structure of the old website.
- Replace the static menu with a WordPress-powered menu.
- Use WordPress'
title tag and leave the wp_head hook in place. - Merge any other relevant tags from the old header.
Let's get into the code!
Original HTML
<!DOCTYPE HTML> <html> <head> <title>Vegan Food Pyramid posters, postcards and wallpapers</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="google-site-verification" content="PO3bWDpUEh4O6XXwnmfyfxrKRDf8JsRrNIcGdzv3POs" /> <link rel="stylesheet" type="text/css" href="style.css" media="screen" /> <link rel="shortcut icon" href="http://www.veganfoodpyramid.com/favicon.ico?v=2" /> <script type="text/javascript" src="//use.typekit.net/tty6xpj.js"></script> <script type="text/javascript">try{Typekit.load();}catch(e){}</script> </head> <body> <a href="http://veganfoodpyramid.com"><h1 id="logo">Vegan Food Pyramid</h1></a> <ul class="menu"> <li><a class="active" href="http://veganfoodpyramid.com">Products</a></li> <li><a href="http://veganfoodpyramid.com/wallpaper.php">Wallpaper</a></li> <li><a href="http://veganfoodpyramid.com/about.php">About</a></li> <li><a href="http://veganfoodpyramid.com/contact.php">Contact</a></li> </ul>
Merged Header (header.php)
<!DOCTYPE html> <html> <head> <title><?php wp_title( '|', true, 'right' ); ?></title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="google-site-verification" content="PO3bWDpUEh4O6XXwnmfyfxrKRDf8JsRrNIcGdzv3POs" /> <link rel="shortcut icon" href="http://www.veganfoodpyramid.com/favicon.ico?v=2" /> <script type="text/javascript" src="//use.typekit.net/tty6xpj.js"></script> <script type="text/javascript">try{Typekit.load();}catch(e){}</script> <?php wp_head(); ?> </head> <body <?php body_class(); ?>> <header> <a href="http://veganfoodpyramid.com"><h1 id="logo">Vegan Food Pyramid</h1></a> <?php wp_nav_menu( array( 'theme_location' => 'primary', 'container' => false, 'menu_class' => 'menu' ) ); ?> </header>
Explanation
One of the challenges of migration is deciding whether to improve code as you go along. Our project has a few areas that could be improved, but Joshua and I agreed to leave them as is. Most of you will be tackling the migration of a design that hasn't been coded to current best practices (although, in fairness to the original coder, they may have been best practices at the time).
If time and opportunity allow, I encourage you to improve on the code. Otherwise, take comfort in the fact that, with the website now on WordPress, improvements will be a whole lot easier down the road.
Let's work through the changes we've made!
- Doctype
Make sure to carry over the same doctype. In this case, the original HTML already has an HTML5 doctype (a relatively rare occurrence on old websites). Using a modern doctype in a code base written for an older specification (such as XHTML or HTML4) could break the layout (especially in old browsers). - Meta tags
I usually bring over the majority of meta tags as is, replacing them in WordPress. The exception in our case is the reference to the style sheet, which is being inserted automatically via wp_enqueue_style in the functions.php file. - Scripts
Scripts can be tricky. If a script belongs on every page (such as a tracking script or font script), then putting it directly in the header (or footer) file is fine. If it needs to appear only on certain pages, then a conditional tag will do the trick. As a best practice, register all scripts and add them to the header (or footer) via wp_enqueue_script. If you're up for the challenge, I recommend doing it this way. (Check out a tutorial on enqueuing TypeKit the right way.) - wp_head
Leave <?php wp_head(); ?> at the bottom of the </head> tag in the merged header file. WordPress uses wp_head, among other things, to enqueue scripts and style sheets that are referenced in the theme (usually in functions.php) and in plugins that you've installed. Without wp_head in place, most front-end plugins won't work. - body_class
Notice our use of the <?php body_class(); ?> tag. WordPress uses this to provide a series of helpful classes to the <body> tag depending on the page being viewed. In our example, the <body> classes weren't being used. Yours might have unique IDs or classes on each page, in which case you can create a custom function using conditional tags to add the appropriate classes to the corresponding pages. Have a look at the Codex for some examples. - WordPress menus
Switching to a WordPress-powered menu is one of the more complex tasks in most basic migrations. It will be fairly straightforward for us. We have a menu with simple markup that uses an active class (generated via PHP) to indicate which page the visitor is viewing. The wp_nav_menu function is highly flexible and offers built-in functionality to handle the current state of an element in the menu. I've updated the references in the style sheet to the active class and changed them to use the equivalent generated by wp_nav_menu, which is current-menu-item. Watch the screencast on importing content to see how I've set up the menu for our example.
And that's a wrap! Let's move on to the next piece.
3. Footer
The footer is usually the most uneventful template in the migration process. As with the header, our objective is to merge the relevant parts of the original source code. Let's get to it!
Original HTML
<div id="footer"><p>© 2013 VeganFoodPyramid.com</p></div> <script type="text/javascript"> var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); </script> <script type="text/javascript"> try { var pageTracker = _gat._getTracker("UA-6992755-1"); pageTracker._trackPageview(); } catch(err) {}</script> </body> </html>
Merged Footer (footer.php)
<div id="footer"><p>© <?php echo date('Y'); ?> VeganFoodPyramid.com</p></div> <script type="text/javascript"> var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); </script> <script type="text/javascript"> try { var pageTracker = _gat._getTracker("UA-6992755-1"); pageTracker._trackPageview(); } catch(err) {}</script> <?php wp_footer(); ?> </body> </html>
Explanation
Some footers are hard to migrate (such as ones with complex menus and widgets), but most are simple. In this case, we've merged the HTML with our footer template, making sure to preserve our reference to the wp_footer hook. We've also changed the date reference to use PHP, ensuring that it updates with each year.
4. Home Page
One of the challenges of a migration is that there are so many different ways to get the job done. The home page is a good illustration of this because it tends to be the most different from the rest of the website. Adopting the simplest method is usually best. I've opted to put all of the home page's content directly in the template. Changes will be rare and can easily be made by editing the template.
Let's look at the code, excluding the header and footer, which we've already covered.
Original HTML
<div id="content"> <div id="poster"> <a href="http://veganfoodpyramid.com/images/Vegan-Food-Pyramid-New.jpg"><img class="product-img" src="http://veganfoodpyramid.com/images/Vegan-Food-Pyramid-New.jpg" /></a> <div class="description"> <h2>Poster</h2> <p>A 30×20-inch poster illustrating over 125 vegan food items as an alternative to the traditional food pyramid. This poster will catch people's attention and serve as a suggestion for food ideas.</p> <h3>$30 each</h3> <p>Includes free shipping worldwide</p> <a class="button" href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2FKQT879CXYYG">Buy</a> </div> </div> <div id="postcard"> <a href="http://veganfoodpyramid.com/images/Vegan-Food-Pyramid-New.jpg"><img class="product-img" src="http://veganfoodpyramid.com/images/postcard-splash.jpg" alt="Postcard Splash" /></a> <div class="description"> <h2>Postcards</h2> <p>Beautiful 4×6 postcards that can be mailed and shared with friends and family. Hand them out at events. Post them on walls. Share the vegan love!</p> <h3>$50 for 50</h3> <p>Includes free shipping worldwide</p> <a class="button" href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=EN387WHNSSFMW">Buy</a> </div> </div> </div> <!-- end content -->
Merged Home Page (/page-templates/front-page.php)
<?php /** * Template Name: Front Page Template */ get_header(); ?> <div id="content"> <div id="poster"> <a href="<?php echo get_stylesheet_directory_uri(); ?>/images/Vegan-Food-Pyramid-New.jpg"><img class="product-img" src="<?php echo get_stylesheet_directory_uri(); ?>/images/Vegan-Food-Pyramid-New.jpg" /></a> <div class="description"> <h2>Poster</h2> <p>A 30×20-inch poster illustrating over 125 vegan food items as an alternative to the traditional food pyramid. This poster will catch people's attention and serve as a suggestion for food ideas.</p> <h3>$30 each</h3> <p>Includes free shipping worldwide</p> <a class="button" href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2FKQT879CXYYG">Buy</a> </div> </div> <div id="postcard"> <a href="<?php echo get_stylesheet_directory_uri(); ?>/images/Vegan-Food-Pyramid-New.jpg"><img class="product-img" src="<?php echo get_stylesheet_directory_uri(); ?>/images/postcard-splash.jpg" alt="Postcard Splash" /></a> <div class="description"> <h2>Postcards</h2> <p>Beautiful 4×6 postcards that can be mailed and shared with friends and family. Hand them out at events. Post them on walls. Share the vegan love!</p> <h3>$50 for 50</h3> <p>Includes free shipping worldwide</p> <a class="button" href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=EN387WHNSSFMW">Buy</a> </div> </div> </div> <!-- end #content --> <?php get_footer(); ?>
Explanation
The front-page.php template begins and ends with a reference to the header and footer that we've just prepared. In between, we'll merge the rest of the HTML, and we'll use the get_stylesheet_directory_uri function, which will dynamically generate references to the images folder in our new theme.
5. Standard Page Template
With the header and footer done, the standard templates are usually quite easy. For brevity's sake, we'll go directly to the merged templates.
Merged Template (page.php)
<?php /** * The template for displaying all pages. */ get_header(); ?> <div id="content"> <?php while ( have_posts() ) : the_post(); ?> <?php get_template_part( 'content', 'page' ); ?> <?php endwhile; ?> </div> <?php get_footer(); ?>
Content Template (content-page.php)
<?php /** * The template used for displaying page content in page.php */ ?> <article <?php post_class(); ?>> <?php the_content(); ?> </article>
Explanation
There are several items to point out here:
- The loop
If you're new to WordPress or programming in general, this piece of code in the #content container might look intimidating. The "loop" is code used by WordPress to display a post's content. You can learn more about the loop in the Codex. Meanwhile, just make sure that it's in there, or else the content you save in WordPress won't show up. - get_template_part
Our page template here employs the handy get_template_part function, which is a great way to keep content organized, especially in complex projects. Our website is simple enough not to warrant it, but I left it in just to show you. - post_class
I also added a reference to <article> (with the corresponding post_class function) to make further customization of the design easier.
5. Full-Width Template (full-width.php)
Although not illustrated in the screencast, the design includes a full-width template for use on the "Wallpaper" page, while the standard page template is changed to a narrow width.
Let's have a look.
Merged Template (templates/full-width.php)
<?php /** * Template Name: Full-Width Template */ get_header(); ?> <div id="content" class="full-width"> <?php while ( have_posts() ) : the_post(); ?> <?php get_template_part( 'content', 'page' ); ?> <?php endwhile; ?> </div> <?php get_footer(); ?>
Explanation
With the template created, all that remains is to assign it to a page. From the "Edit Page" interface, find the "Page Attributes" box (usually right below the "Publish" box) and select "Full-Width Template" from the "Templates" dropdown menu.
6. Extras
Now let's tackle some of the "extras" that sometimes come up as challenges during a WordPress migration.
- Breadcrumbs
Breadcrumbs are relatively common on websites. The easiest way to reproduce them is with a plugin. My current favorite is Breadcrumb NavXT (free). WordPress SEO also offers built-in breadcrumbs. - Widgets
If the design you're migrating has a sidebar, you could either reproduce it as is (the migration theme has a sample sidebar in place) or integrate WordPress widgets to allow for a dynamically managed sidebar. The folks at Automattic have prepared a handy guide to widgetizing themes. Start there. - Restricted content
In case some content needs to be restricted, WordPress offers basic password protection by default. If you want more control, use a plugin. For basic role management and content permissions, I recommend Members (free). For more advanced control (especially if payment is involved), consider Membership (which has basic and premium versions), s2Member (also free and premium) and WP-Members (free). - Custom Post Types
Some migrations, especially ones with a lot of different types of content, call for "custom post types." You can learn about custom post types in the Codex. To set them up, I recommend using a plugin. Two good choices are Custom Post Type UI and Types (both free).
Review Website
Now that we've wrapped up work on the theme, it's time for a review. Work carefully through the pages on the migrated website. For a large website, focus on the different templates. As you review, here are some things to watch out for:
- Broken links
Make sure all links work as they should. If you have only a few pages, you can check manually. For an automated check, use Integrity (free, for Mac) or Xenu's Link Sleuth (free, for Windows). - Broken styles
Occasionally, for one reason or another, a design element of your website might have broken during the migration. Carefully compare the old HTML to the new to make sure you haven't missed any important code and that the corresponding style sheet rules have been carried over. If all else fails, a quick rebuild of the design element on the new website might be in order. - Broken functionality
Test any functionality that you've migrated over, such as "Buy now" buttons, contact forms, newsletter opt-ins, "members-only" content, embedded maps, media players, etc. - Temporary links
Depending on how you've carried out the migration, temporary links to a subfolder or testing domain might appear in your content or theme. You'll want to update these before going live. Use the Search and Replace plugin (free) to check for and update links in your content.
Setting Up Redirects
If your link structure has changed (and it usually will, even if only slightly), make sure that visitors are redirected from the old pages to the new. For small amounts of content, one of the easiest ways to set up redirects is by adding them to the .htaccess file.
Open the .htaccess file in the WordPress directory. If you don't see it, set your FTP client to show hidden files. Now, create redirect rules for each of the old pages. Be sure to put these rules after WordPress' block of rules.
Here are the rewrite rules for our links:
Redirect 301 /wallpaper.php http://veganfoodpyramid.com/wallpaper/ Redirect 301 /about.php http://veganfoodpyramid.com/about/ Redirect 301 /contact.php http://veganfoodpyramid.com/contact/ Redirect 301 /contactthanks.php http://veganfoodpyramid.com/contact/thanks/
If editing your .htaccess file is not an option or if you're dealing with a lot of redirects, then have a look at Redirection (free).
Advanced tip: If the volume of redirects is very high (which is likely with a large-scale migration and a custom importing process), then consider building a function that hooks into template_redirect, compares a generated list of cases, and then uses the wp_redirect function to redirect any matches.
Going Live
Going live with a website usually involves one of two tasks:
- Relocate WordPress from the development folder to the root directory.
- Point the domain name from the old server to the new WordPress server.
Relocating WordPress
If you set up WordPress in a subfolder (as we did), then going live involves a few simple steps. Follow the guide to using a pre-existing subdirectory installation.
Once you've made the change, check immediately for any broken links that you may have missed in the final review.
Pointing to a New Server
If you set up WordPress on a new server, then you probably used a temporary domain. Accordingly, remove references to the temporary domain before pointing the domain to the new server.
Also, if you're planning to update the name servers for your domain, then first resolve any dependencies in the current DNS records (such as hosted email and third-party services). I usually go live with a domain by updating the A records, leaving the name servers in place.
Conclusion
And there you have it! A successful WordPress migration is all about the details, and while this guide is by no means comprehensive, you now have a good outline of the process and a sense of some of the challenges you'll encounter, along with ideas for solving them. If you run into challenges along the way, share them in the comments below. Now get migrating!
(al)
© Jonathan Wold for Smashing Magazine, 2013.
