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.

Existing Functionality

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 Pyramid2. 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 WordPress3. 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.

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 Forms5 ($39+ per license). Other options are Formidable6 (with free and pro versions) and Contact Form 77 (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 SEO478 (free).

Multiple languages
If your old website supports multiple languages, WordPress has you covered. My plugin of choice is WPML9 ($79 per license, free for non-profits). Another option is qTranslate10 (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 WPEngine11, ZippyKid12, Pagely13 and Synthesis14. In addition to managed hosting (and especially if you opt for a non-managed host), consider installing a security plugin, such as Better WP Security15 (free) or Wordfence16 (also free). Last but not least, review the “Hardening WordPress17” 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 VaultPress18 ($15+ a month), CodeGuard19 ($5+ a month), BackupBuddy20 ($75+ per license) and BackWPup21 (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 scripts22 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 repository24 and in third-party marketplaces such as ThemeForest25 and Creative Market26. 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 Chrome28 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 themes29 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 Twelve30). 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 yourself31. (Feel free to suggest improvements!) Let’s get to work.

Download a copy32 (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:

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_style34 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 tag35 will do the trick. As a best practice, register all scripts and add them to the header (or footer) via wp_enqueue_script36. If you’re up for the challenge, I recommend doing it this way. (Check out a tutorial on enqueuing TypeKit37 the right way.)

wp_head
Leave <?php wp_head(); ?> at the bottom of the </head> tag in the merged header file. WordPress uses wp_head38, 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 Codex39 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_menu40 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!

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_footer41 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.

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_uri42 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.

Content Template (content-page.php)

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 loop43 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_part44 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_class45 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.

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 NavXT46 (free). WordPress SEO478 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 themes48. Start there.

Restricted content
In case some content needs to be restricted, WordPress offers basic password protection49 by default. If you want more control, use a plugin. For basic role management and content permissions, I recommend Members50 (free). For more advanced control (especially if payment is involved), consider Membership51 (which has basic and premium versions), s2Member52 (also free and premium) and WP-Members53 (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 Integrity57 (free, for Mac) or Xenu’s Link Sleuth58 (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.

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 Replace59 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.

If editing your .htaccess file is not an option or if you’re dealing with a lot of redirects, then have a look at Redirection60 (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_redirect61, compares a generated list of cases, and then uses the wp_redirect62 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

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!

Jonathan Wold is the husband of a beautiful redhead named Joslyn and the father of a baby boy named Jaiden. He works at Sabramedia, a web design and development company that specializes in WordPress powered media sites. He is also a core developer and evangelist for Newsroom, a newspaper paywall and CMS built for the newspaper industry.

Ertuğrul Sağlam

Cot

Bobby

Very interesting article. Just made the move from static asp classic pages (asp used only for use of include files for header and footer) to WordPress a few weeks ago.

Built a custom spider in PHP that crawled my old site, saved the html to database, stripped away repeated code, ran it through tidy, then manually mapped each page to a newly set up WordPress page list. I used this plugin for quickly creating all the empty pages – http://wordpress.org/extend/plugins/simple-add-pages-or-posts/ – then pushed them straight into WP.

The redirecting was done with the mapping-data in my database (with fields: clean html, old url, WP url) in a custom small classic ASP snippet.

Hell of a process, but the result of getting it all in place – finally – is well worth it. Maintaining the site is for the first time not a one man job, or a total pain. See: http://guide.ffuniverse.nu/ff7/

Alin

WordPress is not a blog CMS ANYMORE. I use WP for any kind of site, from small to medium sizes, from blog to e-commerce, from presentation to creative sites. It’s powerful and easy to use and customize.

0

11

John Saddington

Rachel

I would argue, that while this article goes into great detail and length about the steps of transferring a website from one CMS to WordPress (You can pretty much use the steps outlined above for any CMS), the title should be re-worked. This can easily turn into a complicated process. A bunch of our clients are unhappy on their current CMS, and are shocked to find out how much it costs to build it in another CMS. The problem is that you have to build everything over to fit the “themes” or use the custom CMS elements of the CMS you are transferring to. While dividing it into 5 steps can make it seem “easy,” this is deceiving to clients who know nothing about building websites. The 5 high level steps are loaded with exceptions and scenarios. Also, the import content in an of itself is a beast. Our clients mostly opt to manually do this because the cost for tools that do the import are not cheap, and not to mention, they end up having to go back and fix some character and spacing issues that occur from the transfer. As you can imagine, this is both time consuming and frustrating to them. On some level, I think it allows them to revisit the content and determine the pages that need updating or that can be removed completely, however the changes they make are miniscule to the bulk of the content.

I just don’t think it should ever be said that transferring from one CMS to another is “easy.” It’s basically rebuilding the site in another CMS. Some clients think it’s as simple is “importing” from one system to another with some type of utility, which obviously is not the case.

Veda

Haha, spot on Rachel. The content transfer is by large the hardest part of the process. For those going with large, enterprise sites, check out a company named Kapow out of Texas. They were a tremendous help to us at UNC-Chapel Hill. That said, it was a flawed, expensive process. Money is everything if you’re going with an automated content transfer.

AboutaDirk

Spot on. Also, glad to see a bigger post in between mostly one-liners :]

Perhaps if you run a simple blog it’s easy to swap CMS, and maybe Smashing thinks most readers maintain small business sites, portfolio pages and whatnot. They could well be right in that.

Though, as for all the people that build web apps, e-commerce sites and intranets (etc), they’ll probably see WordPress in the title and think to themselves “ah well, maybe they’ll have something more interesting tomorrow”.

Larry Kokoszka

Guys, you’ve provided a good checklist of items to cover but I agree that there a lot more ‘exceptions’ and ‘scenarios’ that you have to deal with, as well as the issue of working things into themes.

For example, with the Vegan site example, presumably the site owner wants to move to WordPress because they want more control over their content. That being the case, giving them an HTML-heavy page will just lead to frustration on their end and they will, surely, mess up the structure and need to call you to fix it. If they were good enough to do the HTML correctly, they could probably do the migration themselves.

Additionally, the code you were working with in the non-wordpress site was structured 10x better than any HTML to WP conversion I’ve ever done, so I don’t feel that it is realistic.

Really, the best way, imho, to do the ‘wallpaper’ page is set up a wall paper custom post type and make the ‘wallpaper’ link in the main nav go to an archive page. This way, the end user, who (again) doesn’t know html or they would cut and paste it themselves, can just fill in a form in the ‘wallpaper’ custom post type without needing HTML. It’s intuitive and less error prone.

You guys have a very clear writing style and good, short, clear videos, but I would like to see you break this into 5 different posts and deal with the ‘ugly’ stuff in detail. It’s more common that we see that.

Rob McGuire

This is a general outline of a blog migration, but Rachel is right about how some of the key components are breezed over.

I do a lot of HubSpot migrations to WordPress, and I do this with a combination of scripts and manual work which covers topics that many people just don’t realize needs to happen in order for the migration to be successful.

And for custom CMS sites, those vary depending on how the site was originally built and how the database (if it exists) is structured. Some can be bent to allow for easier migration, while others may not have that option and less desirable alternatives have to be explored.

David

@Jonathan Wold – I don’t remember when (and if) I ever saw the full and informative tutorial like the one above. Thank you!

@Rachel, I totally agree that CMS migration is definitely not an easy task, but the post above at least outlines the major points, which better demonstrate the complexity of the whole process. Other than that, I disagree as to the import tools and their price. WordPress offers free import tools for some platforms, there are some reasonably priced extensions too. I used Cms2Cms at http://www.cms2cms.com, it worked awesome to migrate my Joomla website to WordPress, and cost little.

@Arvo, of course, migration is always a risk for SEO (unless your URLs don’t change). But there’s 301 redirect to help you keep most of your rankings (you can see the rules above). However, even if you redirect properly, Google may take its time to index your new location, and until then expect a drop in traffic (my previous site took about 3 weeks to recover). The best plugin is Redirection, (it’s actually mentioned in the post)

Rachel

@David – look into .Net CMS-based import tool pricing :-)
And actually my point was that these tools never completely did the job in it’s fullest. We always have to go back and “clean up” the text and formatting on a bunch of pages, thus defeating the purpose of the import tool.

David Fox

Jonathan Motes

You don’t need a custom-named template for the home page. Files named front-page.php and placed in the theme root are used automatically for the page set as the Front Page in Settings > Reading – eliminating the need to assign a custom template to your Home page.

Ian Arnell

Great write-up, Word press is one of the most powerful and flexible platforms out there right now while still being very simple to use. It can seem overwhelming to move your entire site over but it really will help in the long run. Thanks for showing it isn’t as daunting as one might think!

Jonathan Wold

Linda Watson

I’m stuck half-way through a migration from Squarespace 5 to WordPress. The text content came over fine but I can’t get the images to come among nicely. It’s a pretty big site ( Cook for Good) and I’d like to keep my SEO, such as it is. Any tool suggestions or advice?
Yaaay, vegan food pyramid!

Jonathan Wold

Kristenhanna

Good tips to migrate to WordPress. I hope I can try them out to implement it on my website. And you can also see this recent PPT on Setting up a WordPress websites in this link slideshare.net/kristenhannaa/build-word-press-website-in-25-minutes

Bob

“Migrating A Website To WordPress Is Easier Than You Think”… until you use plugins or themes. Enjoy as you bask in the outdated plugins, 10 copies of 4 different versions of jquery, 4 copies of different versions of the thumbnail php file. WordPress is so much fun!

icand.in

Andy Jones

Great tutorial but with me being a newbie to converting a html site to wordpress it seems a very daunting task i’m debating on just modding a theme up to look like my website but i guess that wouldn’t be exact. Just wish there was a complete guide on how to migrate a html 5 site to wordpress every tutorial i read seems to be missing steps as such.

can anybody please help me do this with a dummies guide ? i feel dumb even though i come from a php background (out of touch now)

Hatim Zuzzer Shamsuddin

Mike

This is wonderful. I am building a site with login page, registration page, member area that allows the users to upload their profile pictures and couples of some social functions. Is it possible to run it on wordpress? (I would want my login & registration pages to be different from wordpress default). Can I run all of these?

Adrian Sane

Very useful post. Im in the process finishing up development on my portfolio site and wanted to have blogging integrated with it. Im still a student and was unsure as to how I would accomplish this. I knew I wanted to use WordPress for my blogging purposes but didnt know how or if I could use my own code in the cms. This made my day. Thanks a ton. Now to do some more research. ..

Brahim BOULOUAYZ

philip Hewitson

Thanks for the detailed guide, I moved my HTML site over to wordpress in May mainly to improve the design and as I find wordpress easier to use, plugins, adding users, scheduling content etc.
The week after I did notice a drop in traffic but thought it would bounce back after a month but it never did.
The site gets new content on a daily basis and has done for a few months now but search engine traffic never seems to grow, on average the search engine traffic is 50 visits a day.
I’ve been tracking some of the pages by monitoring the targeted keywords in serpfox and it’s seems serp positions go from one extreme to another bouncing from high and low pages/positions then disappearing completely.

Do you think I have done something wrong when migrating my site because when it was a HTML site I never had any of these issues or am I missing something?

Paul Braddick

Rubén David Bello Gómez

Hi! I have this website design for a website/blog I have to develop and I have chosen wordpress as my main tool for all the advantages it offers me (tags, users, and everything related with the posts management). The problem comes when I have to adapt the design that can’t be untouched to the future website, the suggestions I read in the article are either create a new theme from the ground or to modify an existing theme, I’ve tried modifying a theme but it’s just too tricky to make it look like my design, I have knowledge in html, css and php, I’d just wish there were some easy way to make it look like my exact design, any help on how to take the first steps will be appreciated.
Thank you.

vladar

Thanks. I knew there is a way. But I am one of those that have different kind of problem. My site is old and by today standards ugly. I want to make new desigh from the scratch but I want to keep using existng detabase. It is property agency web site and you can imagine how big db of 10 years worth of data collecting could be. Is it possible to keep using that db in new wp site?

paul

Krishnakumar K A

Hi, Thank you for this article. I have a free blog posting website using ArticleSetup. I would like to migrate that website to WordPress. Issue with ArticleSetup another website called ArticleSynergy automatically posts Articles. Currently my website Articles crossed 40k! Will it be possible to migrate the website to WordPress?

haidago

I have to migrate a PHP website (non-wordpress, non-CMS) to WordPress 3.8.3!
My real problem is on “Importing content” part. How to modelize the existing datas in WordPress? A priori, there are 6 custom post fields!

How to develop it? I think about using plugins: Pods framework or other!!

Mike Swan

Wow!!! Its really simple to learn the conversion of the CMS into WordPress from your blog…I had gone through many blogs, websites, etc but none of them are easy to learn…Finally, after reading your blog, I get to know more about how to convert the HTML to WordPress in an easy manner…Thanks for sharing the post with us…

Ross

First of all, thanks for providing this tutorial on converting a HTML website to WordPress.

I have a project that I am working on for a client that requires multiple menu’s/navigation bars on five different pages on their website.

For example the home page requires:

Top navigation bar with links to four other pages followed by content and then an additional navigation bar with links to four other pages followed by additional content. The top and bottom navigation bars on each page will have links to different pages.

I have not been able to find a solution for this as yet in WordPress. If I build this site in HTML/CSS, would I be able to migrate this over to WordPress? I have not been able to find a theme that supports the requirement of the Client site.

Thanks in advance for your assistance in answering this question.

Home-top-nav-bar
Content
Home-bottom-nav-bar
Content

On the About Us page this pattern would be repeated
About-us-top-nav-bar
Content
About-us_nav_bar
Content

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

SmashingConf isn't the eighth wonder of the world, but we are pretty close. Join us at SmashingConf Oxford on March 16–19 or meet us at the shores of Santa Monica for SmashingConf LA on April 27–30. You won't be disappointed.