Agency Breakout Summit/2020: Mastering Migration—How to Manage a Move From Another CMS to WordPress with Confidence

The flexibility, extendability, and scale of WordPress makes it a very attractive option for businesses considering a CMS migration. However, a CMS migration can present a number of unique challenges for project teams, particularly for sites with complex implementations. In this video, Leo Postovoit, Head of Partnerships and Product Strategy from XWP takes a look at a number of tools and strategies implemented by migration specialist agencies that massively streamline the process, ultimately minimizing the risks of change and equipping your business to unlock the potential of WordPress sooner.

Video recording of session

Leo Postovoit, Head of Partnerships and Product Strategy from XWP discusses: 

  • What should be considered when making the move to WordPress? 
  • How hard will the move be? 
  • What does planning and execution look like?

A good migration is one that is methodical, a bad migration usually involves you skipping steps.

Slides from the session

Full text transcript


– Hi, everyone, welcome. We’re here today to talk about Mastering Migration, How To Manage A Move From Another CMS To WordPress With Confidence.


My name is Leo Postovoit, I’m head of partnerships and product strategy for XWP. In my free time, if I have any, I’m also a WordPress component maintainer for Core Privacy, which means I contribute to WordPress Core, doing lots of cool stuff in all kinds of different ways.


Before I came to XWP, doing enterprise WordPress agency stuff, I worked in journalism, doing stuff for media organizations, and lots of cool things that are pretty powerful and I thought a lot about what publishing looks like in the enterprise space.


So today as we talk about moving to WordPress, we’re gonna consider a couple of different areas.


First of all, should I move to WordPress?


Second, if I do, how hard will it be?


Third, what does planning execution look like?


And fourth, what are the gotchas and how do I best tackle them on my given project?


So in the first general topic, I wanna talk a little bit about the details you might care about that should come up as you start to navigate whether WordPress is a good solution.


So there are generally three different areas.


First is WordPress is open source, second, there are many tools available and third, WordPress is pretty reliable. In the open source space, that means you generally don’t have to worry about being locked to a vendor, tied into their entire ecosystem, and not having the ability to be able to come and go as you please.


You also have the ability to really study the program to run it however you want, to be able to make modifications, you’re not necessarily tied to a given project, you can do essentially whatever you want, you could fork it if you want it to.


Second, as you start to tackle within the elements of WordPress’s tools, you’ve really got to understand that it has a lot of things available to you.


So you might be familiar already with plugins and themes but it goes much further into things that are really deep and technical, things like the REST API and the WP-CLI.


We also have really reliable partners in the WordPress space, people like us at XWP and WP Engine, that can help you as you grow and scale your business and helping you navigate that discussion on the enterprise space.


And finally WordPress powers up to 36% of the internet and it’s growing.


This means that you have a lot of things built in terms of long term maintenance and core support.


If you are considering WordPress, you should be able to have the guarantee that it’s going to be around for the next five, 10, 15 years.


It’s unlikely that we’re going to see that WordPress is going to shrink but instead continue to grow on its current trajectory.


That being said, we also think it’s really important to evaluate other solutions that might exist, so whether these are open source solutions in the publishing space like Drupal, or in the e-commerce space, like Magento, or cloud based solutions or the equivalent, things like Arc and Chorus in the publishing side or say Shopify or BigCommerce on the SaaS side.


If you’re really crazy and you’re just have this idea of doing your own kind of director


of engineering type thing and you want to roll your own, you could, you might actually have some really interesting rewards, you might actually be faster than WordPress, or even better than WordPress or even better than any of the other existing solutions on the marketplace, but there’s a little bit of a risk,


You’re gonna be doing a lot more software development and building your own CMS is a very laborious process and a lot of corner cases so you could consider doing these things but I always go back to this question about whether WordPress is the right answer and oftentimes it is a great answer and so I would recommend considering how that feels right for you in the in that given scenario.


So let’s say you’ve decided WordPress, let’s tackle how difficult that might be, considering the approach that you should take given your skill sets or the project’s requirements and needs.


The first thing that we recommend doing is a SWOT analysis, so that’s strengths, weaknesses, opportunities and threats.


From that very first sort of initial review of the site,  you should be considering which platform do I want?


What are the weaknesses of this given platform?


What are the opportunities you might gain?


What are the threats that might actually hurt us in this project?


This is a really normal business analysis to be able to understand what’s going on.


As we tackle the things in terms of difficulty level, there’s a couple things I like to consider.


Is this a Greenfield project? Do I really care if I move all the content over, or is it really critical? Should you just go for it?


Do you really need to really track every element or should you be focusing on a sort of white glove experience?


So if you have a reliable partner like XWP or WP Engine, you might end up more in that second category where you care a lot of the different elements, making sure you’re not just porting data over but instead making sure you’re mapping that data in a way that’s gonna be reliable


And the third point, I think, is also relevant. This is about doing it for fun versus just actual real sensitive client projects.


So if you’re an engineer early in your career, and you just wanna know, “Can I move insert CMS to WordPress?”


Then yeah, go for it, do it just for fun but if you’re talking about enterprise migrations, talking about big companies that are really worried about this, that make 10s or 20s or hundreds of millions of dollars a year, you really wanna consider that you’re gonna have a lot of planning that’s required to do it the right way.


And if you have many sites you might consider that are moving over, you have a different approach versus just a Single Site and even with that you might have to consider all the elements that are built inside of it


And if you end up in one scenario, you might find that you have a couple different approaches that might make sense for it but it’ll ultimately depend on your final use cases.


Finally, the biggest element here I’d like to talk about is how you port that content over in terms of that structure of data.


So we today are currently pushing most people to consider Gutenberg the block editor, as a normal approach.


You might also consider the classic editor to be a real solution depending on what your goals are, potentially even other solutions


So within WordPress, there are things that heavily leverage post meta, things like advanced custom fields, that might actually be a quite useful solution for your given migration project.


In the normal migration category, so like what is the typical migration look like for a site that’s not that complicated, that also doesn’t have to worry too much about scaling, that is more Greenfield as opposed to white one.


We’re gonna to consider using as many off the shelf tools as possible.


Things like WP all import which allow you to import standard files off the shelf CSVs and JSON files and XML files can be mapped directly to fields in WordPress in a structured way.


If you’re talking Drupal, there are quite a few tools.


One of the best ones I found is FG Drupal to WordPress, but it’s essentially almost a Turnkey Migration, so we’re talking about vanilla Drupal to vanilla WordPress,


It’s relatively easy to move that content over.


If you’re not in a vanilla scenario, things might be a little bit different.


There’s also the default tools that are built into WordPress that provide importability, so if you’re moving from say, a social media platform like Tumblr or Blogger to WordPress, a lot of this will come out of the box, so you don’t necessarily have to worry too much about that.


Another big thing about our normal migration, an easier migration, is you’re not necessarily concerned as much about the front end and a full lift and shift,


You’re mostly gonna use a prebuilt theme and you’re mostly gonna move things over and as you sort of move into this, you also consider that maintenance mode is probably going to be turned on.


The site may go down for a couple of hours or a couple of days and it won’t necessarily break everything for you and it’s honestly not common for most sites that we see at XWP but it might be a scenario that might come up for you because your sites simply don’t necessarily have as much risk associated with them at the go down over a short period of time.


As we look into the next phase, the sort of intermediate style migration.


This is at least for us what a small migration might look like.


We’re often times considering a bunch of different questions.


One of those might be redesigned versus lift and shift. Are we changing the theme? Or is it gonna look exactly like it did on the other CMS.


Also a lot of data mapping  and migration might actually need to be done by hand, so this means that you can’t just use a plugin, you’re probably gonna have to write some scripts, so this could be a Bash script might be a WP-CLI script but we’re gonna to try to automate this in some flavor as early as possible.


And this means that we’re gonna have to consider content freezes and code freezes as part of what we do and maintenance mode is still probably gonna need to be a thing to consider in.


We also need to consider what happens when this data is being used in the wild. 


So tools like Elastic Search or SOLR are gonna be really important, and we may also want to call the strategies to allow you to continue to use the old CMS as you migrate over.


A good example of intermediate migration as it relates to the work we develop at XWP, would be the work we’ve done with Nova, so this means that we’re considering all the right things we’re migrating to, so what benefits might WP Engine be able to give us with the platform tooling?


So we considered using the Geolocation API, for example, to give each of these radio sites, the local radio station, as well as the best things that we as our agency could provide. 


So how do we best leverage PWA to be able to enable the best that your site may be able to give you. 


So for us that meant using AMP as a data source, so really high indexable content that plays well with Google News carousel, but also PWA so you have an installable offline experience for giving users in the wild


The effort here is more intermediate because it’s relatively methodical to move from Drupal to WordPress and we could consider how that migration pathway would look like and we did leverage some elements of redirection and combination but it’s actually for us right in the middle of the intermediate and the advanced stage.


And that’s because in the advanced stage, we had to consider a lot more stuff going on, so for these kinds of projects, we’re considering things that are in flight that can’t go down, that where really you might have a little bit of elements of downtime but you really wanna make sure that availability never disappears.


So oftentimes this means building extensive REST API solutions that consider how to not lose data so how do you allow for the site to not ever disappear?


So if you have a store, for example, and you’re moving from one platform to another, how do you avoid that store going down because if a store is selling X number of products in a given hour, every hour that’s down, that’s how much money that company might potentially be losing.


Similarly, we think about this as a rollout strategy so with Nova, it was a little bit easier, but as we’ll see with the next case study, you sometimes need a lot of things to consider in terms of larger processing data, especially when we look at like large decades of archives.


When it comes down to this, we have to think about data migration and mapping by hand.


In the case of Nova because we’re moving from Drupal to WordPress, it’s a much simpler migration, that is all structured in the same way.


Whereas when we look at moving from say a custom CMS to WordPress, we’re gonna have to consider each of the elements of how that data might be structured and so sometimes you might actually need to crawl and scrape these elements to make it make sense in that given platform.


Finally the last element to consider here for these hardcore sort of more advanced migrations is when and to what extent do you migrate?


Do go full in and you do it in the fall? Do you do in the winter? Do it in the spring?


If you’re doing things like e-commerce, and the holiday season matters, migrating in say, October, November, December, it’s probably not the best time of year if you’re considering,

say, the Christmas season that might impact directly your bottom line.


So when we look at a large site like Rolling Stone, or any really large site that is considering migration, one of the things we wanna make sure we consider is what are all the elements that a site could have as a detail that might impact its migration checklist?


So this is everything from do I need to be worried about user data? Or does the front end have any issues that might come up for availability across regions? 


This means that we need to document as much as possible and create repeatable, deployable, testable elements of this given site, so this means both on the engineering side and on the QA people side, so we wanna test things that we feel really comfortable with.


Oftentimes clients think it should just work but QA means we want to make sure it works as well as possible.


We also want to consider each of the elements that the stakeholders that actually are really powering the site have these elements considered in that platform?


And as we do the documentation elements within this given site, we oftentimes want to leave things behind, so when we do that migration, we really wanna make sure we save all the things we need to, build on the things that really do matter and leave behind the things that don’t.


So if we actually feel really comfortable with the migration, we should be able to press a single big red button, turn everything live as we did with Rolling Stone.


When you finally do go live, another big element we would say is testing, testing, testing, so this means QA, this means code review, this means testing even some more.


I know it seems like a lot but the more testing do, the more likely it is that you’re not gonna have something major happen and if you do, you’ll be able to understand it and respond to it in a timely manner. 


And these kinds of things might look like different shapes and colors based on the the kinds of things you do for your site.


Oftentimes, this means really really large migrations might require tons of data that has to get processed, so my recommendation is to sort of just in time approach, so process the bulk of your data about a week before the go-live, so you only have to process a diff of that data at the final stage.


This means you can leverage all the resources that you have of time beforehand, you don’t have to worry about anything. 


And in the case of a Rolling Stone type migration, you can leverage cloud resources to help scale up processing.


You also have the ability and to prepare and predict the problems that might happen with media assets and CDNs, so as you move stuff over, things might break and there are variety of different factors that might come into this and different partners may be able to help you here.


One thing that sometimes people forget is that as you process each media asset coming in, you generate thumbnails.


Those thumbnails will generate space and complexity and confusion and if you only allocated for a certain amount of space, you might end up consuming all of that space and putting yourself in a really strange scenario.


Another big element that sounds obvious is that make sure your site works well in the live space, so if you have robots crawling the site, if you have humans crawling the site, you really wanna make sure that after you’ve migrated that content, that it’s available in the same way that it was before


And so oftentimes doing a pre-review to make sure that it was working well and a post review to make sure that it’s working at least just as well and ideally better, you should feel really

confident with that work. 


And of course, testing matters, QA matters, updates matter, doing all these things matter in a way that you should feel reliable about that site and if you don’t do it, these gotchas will probably bite you.


So in conclusion, we’ve covered four different areas of what happens when you think about migrations with WordPress.


First question is should I move to WordPress? The answer is probably.


Will it be hard? Well, probably a little bit depending on the level of complexity it might be more challenging, it might be less challenging,


In terms of planning, we know it’s really important not to skimp and we also recognize that there is gonna be gotchas but as long as you Plan and Document these things along the way, you should feel really confident with this good work


And now let’s jump to the live feed for questions.




– All right, welcome back. This is our third AMA Q&A for the agency track sessions.


Just wrapping up with Mastering Migration, How To Manage The Move From Other CMS To WordPress, a topic that I’m extremely passionate about because I love when people move over from other CMS’ to WordPress.


I’m here joined with Leo Postovoit, Head of Partnerships with XWP, got a few questions here that are teed up and we’re getting ready to go here.


So. Let’s see, how do you determine. Leo first one is, how do you determine lead

time of a complex migration?



– That’s a good question, so at XWP we start off every project with a discovery process to really unpack and describe exactly what the requirements of a migration are going to be. 


So we usually have to build in at the very bare minimum for WordPress project, time to create some scaffolding for the plugins and beams are gonna be necessary for this given site to make sure that CI/CD pipelines are built out the way that we like.


So we generally speaking use automated deployment across the board, we also integrate code centers, so we know that there’s gonna be a bulk of a project that it’s usually two to three weeks that are essentially like necessary for us to set up and do some probing.


Within that we’ve done dozens and dozens of migrations over the years. so we really wanna make sure that, does this feel right?


Does it feel about as big or as small? So we start with relative estimating, we start with some base and then we can usually predict pretty quickly, like is this a big project or is it a small project.


With more technical migrations, a lot of it comes down to data mapping, so from Drupal the entity model is similar to WordPress but not necessarily.


If a tool has an API, we can assume there is structured content that can probably come into a custom post types custom taxonomies but if it’s completely like no CMS, or maybe it’s just static HTML pages and we have to rebuild everything and probably consume it, like we expect it to be months, not weeks and definitely not days, so it’s tailor-made.



– Absolutely, for each engagement, custom opportunity and then you guys do a really good job of executing.


One question is, headless, it’s a big topic of conversation here at Summit, it’s been around forever but WordPress is now becoming more and more prominent within the the headless space, so are you seeing more numbers and more requests to move, WordPress into headless with these migrations, from other platforms?



– Yeah, definitely, so we are huge fans of the REST API, most of the people on our team that they do a pretty intensive stuff with REST APIs, are part of our WordPress core teams,


We’ve built out features, right now we’re working on a few things involving authentication, which is super exciting.


For most of the projects that we do, we end up creating custom REST endpoints but I would say that and this is may be a little bit of a hot take on the headless thing.


I think headless can be incredible when done well but also may add unnecessary complexity so we’ve had a couple of instances where we actually brought back headless sites to sort of the more, normal head full WordPress experience. 


So if you’re going to be doing headless, the question I think you should ask is, is this right for this given experience?


So if you’ve got like a WooCommerce product page that’s just lots of filtering, lots of events sorting, you can create custom endpoints or use WooCommerce’s default endpoints to create a really cool headless container inside your regular head full WordPress if you will.


Use the REST API’s where they should be, don’t necessarily go entirely Greenfield unless you really have needs for those API’s to be used elsewhere beyond just a single view container.



– Yeah, so basically if it’s a pretty standard, regular tiered architecture, with the requirements and not a real need for advanced de-coupling as well as the expertise for the organization that’s driving the chang,e may not be worth going, you know in a headless solution.


You’ve seen the opposite of people moving from headless back to full body plus head,



– We see both, so if you’re ultimately syndicating content beyond just the regular publishing workflow if you will, if you don’t need just generate static HTML pages and you really do need a REST API to be available to other services, by all means, like we recommend go headless, go consider these crazy advanced features.


We did some pretty cool work a couple years ago with Beachbody where we inside customizer using change sets and a bunch of other things, powered OTT devices, so like your Roku, your Amazon, your Apple TV experiences, but also this really powerful web app, also all these devices and it just depends on what you really need,


Most publishers don’t need something that complicated, but they might have components that really do require intensive use of the REST API, so I’d say find the right use case if you are gonna go around the world of headless.



– Right, that’s really good stuff and finding the right situations to make those leaps.


Here’s a good one, so migrations, they’re very scary, especially from other CMS platforms. What’s the easiest way to ease that fear?


Since you’re relatively experienced at this, the audience wants to know.



– So I would recommend testing and documentation, dry runs, scripting everything.


If you are having to do a migration by hand, and again, I mentioned this early on in the talk, if it’s not necessarily just for fun, that’s for serious business.


If you actually want to make sure that you’re not losing anything, you need to do everything you can to have a plan in place and then you just follow that plan to the letter.


A good migration is one that is methodical, a bad migration usually involves you skipping steps, so if you have multiple properties, so we oftentimes deal with networks of sites, 90 sites, 100 sites, 200 sites or whatever it might be,


When some cases like I know right now Tumblr is moving its entire architecture to WordPress. That’s gonna be really scary super massive migration.


I would recommend that they don’t move at all at once, they start with a couple of sites and maybe one category or one vertical and sometimes you can even run a split experience where like just one section of the site is running on WordPress and maybe the the rest of the site is still running on the other CMS.


Every use case is a little bit different and sometimes you see that you might need a broader approach to be able to do that full migration, especially in sort of what I call the advanced tier of chaos-style migrations, where there’s so much going on underneath the hood.



– Yeah, absolutely, that’s a really good point. 


You  mentioned make sure you plan, test, plan, test, plan, test, be prepared but there’s always those gotchas.


So what are some of those gotchas that the folks that are listening, what are some of those gotchas that they should be prepared for? Those unexpected expecteds that you’ve had, during the years of this type of work?



– Yeah, I think the easiest one that we tend to see a lot of, is people don’t realize the complexity of media assets, so you probably already have a very messy, very clunky media asset experience, probably too many pictures, they’re probably not optimized they could probably be better used, they could probably better merge into your experience on WordPress, leveraging s3 or cloud in there, some other type service where you offload a bunch of that processing.


In your imports and in your migration, if you don’t consider this, suddenly most of your file space will expand at a pretty crazy rate.


Additionally, your database will expand at a pretty crazy rate and you have to be really careful about how you manage that.


I think I also mentioned around processing, it’s best to try to consider your database as a large entity, or large set of entities,


If you can figure out how to migrate 90-95% as much as possible before your actual go live date, it means that most of the work you’re gonna be doing is much smaller and then also another big one I sometimes forget to mention because I think it’s so critical, we really shouldn’t forget it, is SEO.


So you should be reviewing your site beforehand, tracking and understanding how you were doing before you did anything and then after you migrate, do all that same testing again to validate, did I miss anything? Is our pages randomly now indexing and they shouldn’t be?


Are pages not indexing and they should be? 


Trying to get as much understanding of these kinds of gotchas upfront and planning for them and expecting them to go wrong and then being really happy when they don’t, is a little bit more way to manage this entity of migration.



– Absolutely, it’s good stuff but almost along the lines of expect the worst, hope for the best but with migrations, nothing’s certain,


Multi Site is one of the benefits of WordPress and a lot of organizations take advantage of that functionality.


Are there any common mistakes that you run into with Multi Site when making the migration?



Yeah, so Multi Site is a fantastic way to really think about WordPress at scale.


The one thing that I see and again I’m gonna give my little bit of a hot take on this.


Sometimes people jump into Multi Site without recognizing all the complexities.


So you’re talking about N number of sites and N number of databases times the number of databases that would be the Single Site.


So optimizing for Multi Site is a little bit harder than just building out a regular WordPress site.


Also security and plugin activations requirements and development becomes all a little bit more complicated, so if you’re going to do Multi Site, the first question I would be asking is, do you have a shared set of users that really need to be able to access every one of these sites?


And if this is something that really needs to have syndication or REST API shared across the board, or some sense of shared data, that can’t be accomplished easily with the REST API, Multi Site might be a good answer.


I usually see people coming to us on the inverse, asking us to take this really complicated Multi Site and blow it up into a bunch of Single Sites or take this multi-network Multi Site, so the biggest scale of Multi Site, and integrate back into regular Multi Site,


So it’s not necessarily a bad thing to go big, it’s just about when and to what extent and they’re likely is an easier solution, a simpler solution. 


Leveraging as we talked about earlier about headless, the headless style approaches, where you’re consuming small pieces of data, especially on things like public API’s, you’re just getting posts as a result in a feed or something like a REST API can totally solve that without the overhead of oversight.



– Absolutely and it just really comes down to like setting those those expectations with the client, it sounds like.


Are they a right fit? Do they have the right capabilities? Set those expectations, plan, test, execute appropriately.


In any sort of a, I would say, a little bit more of a bespoke process when you’re looking at complex and you guys worked a lot in the enterprise, types of migrations from other platforms to WordPress.



– Yeah, I’d say one step further just as well ’cause I think it’s also critical, like we would rather have a smaller, easier-to-maintain component than even arguing for full Multi Site, so not that it’s a bad thing, like Multi Site has really great purposes but we really want to try to do right by our clients and it’s not necessarily about using our entire potential budget, it’s really about making sure they have the right thing that’s gonna make sense yourself.



– Absolutely and one of the things as we, expand upon the knowledge and expertise that you have, a lot of it is experience-based but there’s always that knowledge you can gain from others and resources and materials, books et cetera.


What do you recommend for those out there that are taking on more complex migrations? What are some of the resources that they can go to learn more?



– Yeah, so we do a pretty good job of trying to describe some of the complexities we deal with in terms of migrations as part of our case studies on our site.


WordPress core contributors do a lot of examples of how these migration patterns look like inside WordPress.


I’d also point to it depending on how complex or how crazy your migrations might be to some of the examples of people using Cloud Functions and similar types of cloud API services to do really hardcore migration.


So for example if you need to crawl a web page and then generates structured data based on that, that can be imported in as post types, which is basically how we did Rolling Stone.


They had 20 years of CMS legacy data, no SOAP API, no REST API, just they essentially gave us that out of HTML pages.


If you have to build a structure out of something, you don’t wanna do that using local machines.


You wanna do that using scalable processing power, so going down the the cloud world of things and learning a little bit more about the harder world of things involving development at this point will be a lot more useful for you and you’d be surprised at how much these things like Cloud Functions can provide you utility, even beyond just the scope of migration, so for us, it’s something that’s making a big part of our business.



– So I guess the same isn’t true, sounds like Rolling Stone did gather a lot of moss of content over the years. 


So one last question here as we move around to wrapping up.


One of the things, one of the items that a lot of the folks are asking is, the partnership with WP Engine, so how are we helping with this migration during the process with some of these migrations from other platforms to WP Engine?



– Yeah, so I mentioned CI/CD pipelines, I’ve mentioned a little bit about staging environments.


You wanna be testing this along the way so if you work and again the WP Engine has many different kinds of plans and many different kinds of features.


The more enterprise you get, there are certain access pieces that make it a little bit easier to do advanced CI/CD functions, makes it a little easier to do things like automated deployments.


You also have the ability to use API’s to determine uptime and do other things that’s quite cool.


If you need these functions, I’d be reaching out to your local WP Engine person to make sure that you have all those things available to your team and again you want to build this into your staging production divided mindset process, so as early as possible, you should be trying to make it easier on your development team, so they can focus on the harder problems to solve and the big, big role of working with a good technology partner is that their entire methodology is to make it as easy as possible to do the biggest biggest things with the least effort.



– Absolutely, thank you and we do appreciate  the partnership and providing us with your knowledge today on something that we’re very passionate about as we continue to gain more market share, WordPress as a whole and community,  and like I said, really excited to see a lot of the the migrations from legacy platforms as marketing budgets change in a new era and so it’s really exciting stuff and we’re here to take advantage of it,


So quick thank you again Leo XWP, wanna thank some of our other partners as well, American Eagle, Maark, Crowd Favorite, our wonderful production team here at WP Engine, Chris Garrett, Sinziana is helping us out with the curation of questions and J-Mac with audio and Imran did an amazing job as well, so thank you very much for all of your time today on these agency tracks and take care, and thank you again Leo.



– Thank you, take care.


Get started

Build faster, protect your brand, and grow your business with a WordPress platform built to power remarkable online experiences.