If your aging, inflexible content management system is to blame for poor site performance, non-stop content workflow delays, and content creator frustration over its usability, consider “cutting the CMS cord.” And moving to a more agile solution that better supports your digital strategy.

We know migrating a website or tech stack is a daunting task. For large businesses with dozens of sites, thousands of web pages, and extensive content libraries, “getting it right” means knowing the risks and pitfalls—and what business success really looks like.

Fortunately, for our live session Everything You Need to Know About Migrating to WordPress VIP, we’ve assembled a trio of migration experts who’ve seen it all and successfully led migrations across the globe.

Key takeaways:

What you need to know (and watch out for) when moving from self-hosted WordPress, Drupal, Sitecore, or bespoke CMSes to an enterprise-grade WordPress infrastructure—from scoping the project and setting realistic project timelines to aligning stakeholders for success.

Deep technical considerations for any migration, from design and taxonomy, managing SEO, data export, and image optimization to article mapping—so you can avoid “timeline blowouts.”

Key benefits organizations realize—like better handling of traffic spikes, content optimization, and democratizing the publishing process—by migrating to WordPress VIP, a secure, agile, and scalable CMS.

Transcript

Enfys Book:

Hello everybody. We’ll be getting started in just a moment. Welcome everyone. We’ll be getting started in just a couple minutes here. Give folks a chance to come in.

All right, I think we’re going to go ahead and get started now. Just to let folks know this is going to be recorded. So, if you’re not able to make it for the entire thing, you should be able to access it later. Thank you so much for joining us. I’m Enfys Book, I am a launch technical account manager with WordPress VIP, and I thought we could start today with some introductions. One thing I wanted to let folks know is with GoToWebinar, you can minimize the slides, if you’d prefer to see the speakers larger, so you have that control. There are also some other options. You’re going to see a question box, and we hope to have time for Q&A at the end of the session. So, please put your questions in the question box during the session.

So, let’s start. I’ll introduce myself and then I’m going to pass it to Ben. I’m Enfys Book. I have been migrating white websites throughout my 21-year career in digital communications. In my current position as a launch technical account manager with WordPress VIP, I help guide enterprise level customers through the onboarding and migration process. Before this, I migrated and managed websites for agencies of the US federal government, a tech startup and nonprofits. Ben.

Ben May:

Thanks Enfys. I’m the founder of the Code Company. I’m based in Brisbane, in Australia. We’re a technical agency that help media companies leverage WordPress, and over the last 10 years I’ve managed a number of large scale WordPress migrations through to VIP and keen to talk about that today.

Enfys Book:

Thank you. Francois.

Francois Joubert:

Thanks Enfys. I’m Francois Joubert. I’m the Vice President of Technology for RE/MAX Canada. So, I look after everything technology for them, drive IT strategy. My background’s largely financial services, and more recently real estate, and a new client of WordPress VIP.

Enfys Book:

Great. Thank you everyone. So, let’s start off talking about migrating with, “Why is it important to get migrations right?” I’d love to hear from… Why don’t we start with Francois on this one?

Francois Joubert:

Okay. Largely for me to make sure that that customer experience is really good. So, you don’t want to interrupt your customer experience or impact that customer experience in any way. There’s obviously a large brand attached, and a lot of brand value that you can impact when you get these migrations wrong. Then some of the more technical points in our industry at least, and for most of people out there, we spend a lot of time on digital marketing, a lot of time on SEO. If your migration does not go well, the impact on those points are substantial. It takes a really long time to recover any slide that you have in SEO, as an example.

Enfys Book:

Absolutely. Ben, what are your thoughts?

Ben May:

Yeah, any migration of any application at a big picture, there’s business continuity risk, really, at our highest level, and then you work backwards from there. Depending if your business is digital first, and heavily depends on that platform. You’re thinking through things like Francois said about customer experience and impact to operations. If you’re taking e-commerce payments, or affiliate marketing, all these kinds of things, they can be calculated an actual cost per minute of downtime, or issues like just in the straight migration. But then also doing any migration is managing the before and after, and the difference in any regressions, things like that. So, loss of functionality, change of functionality, things like that. There’s a hundred ways to think about that further down, in more detail.

Enfys Book:

Absolutely. For my 2 cents, having been migrating websites literally since my first task at my first job out of college, that was job one, move the website. I just know from experience, there are so many variables at play with a migration, and a lot of times a lot of different people who maybe don’t usually work together are impacted by a migration. So, it’s important to get buy-in from across the organization early, and to have a good sense of who are the key people who need to be involved, informed, and so on throughout. Because unfortunately, if a migration is done poorly, it may take a lot longer, and it could add a lot of technical debt that’s going to need to be resolved later. So, let’s talk about how we prepare for a migration. We’ve established that preparation is essential. I know Francois did a fantastic job preparing for their migration, so would you mind telling us more about what you did?

Francois Joubert:

Of course. I think the most important thing for me, always when I start these type of projects is really understanding the business objectives. So, why are we doing this migration in the first place? That obviously ranges from real technical aspects, or things like performance or stability, usability or all the way to things we’re trying to achieve in terms of our user experience or where we want to go in terms of SEO or scale. So, having a good idea of business objectives we’re trying to meet and then crafting your plan from there. We spent a really long time just auditing what we had, making sure that we understand exactly where, what functionality we have, what features we have, and to tie it to Ben’s point earlier, when you go through the migration, you don’t want to get to the other end and then realize, “Oh, I’ve missed these requirements, or I no longer have this feature, and it’s going to take me X amount of time to put that back in place.” So, those typically are the two key things that I would really spend a lot of time focusing on.

Enfys Book:

Yeah, I remember one of the things with your migration as well, you spent a lot of time reading the documentation ahead of time and making sure that things were going to work, and that’s something that I know made things a lot smoother and quicker once you got access to the environment.

Francois Joubert:

[inaudible 00:08:04] Apologies Ben. I said definitely we were joking about that, but reading the manual helps in most cases. So, when you’re doing a technical project that’s fairly complicated.

Ben May:

I was just going to jump in and say as well, I think when you’re planning one of these migrations, it’s that traditional change management technique. A lot of businesses probably go in thinking, “This can just be led by a digital project manager somewhere further down the line and not impact the rest of the business.” But if you are selling ad operations through to commercial activities, the amount of considerations we’ve had in launches where you get just to that point where we’re trying to schedule an actual date, now we’re pretty close, and then all of a sudden, “Oh, we can’t do here because we’ve got a big campaign running at this point,” or, “There’s actually an editorial event, there’s an election. We can’t risk migrating that weekend because there as a sports event, or an election, or a TV series finale, or whatever else.”

So, change management is that discipline of organization-wide being involved and understanding what’s going on. One of the other biggest ones is this purpose of why we’re doing… Like Francois said what the reason is, and understanding is it just a straight migration and repurposing to move, or is it a complete re-imagining? So, we often say if we’re doing just re-platforming, we’re not trying to adjust functionality, we’re trying to keep a baseline so we can measure and work from there onwards. Otherwise, it turns into a totally different scope. But as long as people have that clear expectation, are we re-platforming or are we re-imagining the whole thing? It’s really important just everyone’s on the same page about that.

Enfys Book:

Absolutely. I hear when you are just moving it from one place to another, there’s risk that comes with that, that you’re not going to literally be able to keep all the same code, and all the same functionality because your platform may have different capabilities and restrictions from where you’re coming from. So, evaluating all that stuff ahead of time can really help limit the number of surprises you encounter as you go through your migration.

I think it’s also really helpful to set realistic expectations among your stakeholders, especially in terms of how long it might take, and also making sure that you understand exactly who needs to approve the site before it gets launched, and how long it may realistically take to do that. I have been through some launches where they wanted to launch on X date, and then that date would arrive, but they still didn’t have their final approvals, they had to move it, and then they still didn’t have that final approval, had to move it again. That’s not an ideal situation. So, making sure you have early buy-in and understanding of what needs to be approved and when, I think is really important.

So, let’s talk a little bit about types of migrations. We’ve already alluded to that lift and shift one, where it’s like we’re keeping everything the same and moving it as best we can. What are some other types of migrations you all have worked with?

Ben May:

I can take a first shot at that, and the main concepts we talk about when we work with partners in doing migrations is, especially in the digital media world where content is changing every minute, and content’s being published, articles are having comments and data’s changing all the time. So, the two primary concepts are this idea of you pick something up, you drop it down, and run it through a process to update it and make it work so you have some content freeze, or code freeze, or combination of both. Then, there’s the other concept where you are running potentially a bigger migration, and either wanting to run things in parallel, or you need to do a lot more crunching to get the data across. Is this idea of a continuous data migration where a legacy system, and a new system are coexisting together and data is synchronizing between these environments in real time.

That definitely has a lot of advantages, especially from a testing perspective and the ability to launch at any moment with almost no downtime or no issues there, but there’s obviously a lot more inherent work and testing to make sure. Especially if you’re doing a migration out of another CMS, so it’s not a WordPress to WordPress. WordPress to WordPress can usually be a few steps removed by providing VIP team the WordPress database, as you need it and things like this. But if it’s coming from a Bespoke CMS or another CMS, the data needs to be scrubbed and cleaned and reorganized and tested. Continuous data migrations definitely have a lot of advantages there, because you’re able to almost look at two sites in real time, and do testing that way.

Enfys Book:

Absolutely. Francois, did you have anything to add there?

Francois Joubert:

I could give one variation on what Ben described. I think the positions I’ve always been in is the CMS is always a portion of a larger Bespoke transactional website. So, we’d have typical financial services functions in a website that’s really custom-built and the CMS is used to supplement that, and manage our digital marketing efforts, and take content out of the hands of the developers and give it to the business teams to be able to do that. So, what I personally like doing with those scenarios is launching parallel, in a way, but you can launch almost MVP with WordPress, the CMS on the side, and just build it up over time. So, you almost take away that continuous synchronization of data between the two CMS’s. The one just builds up and the other one gradually retires in the background. But it really depends on what your architecture landscape looks like, and what options you have. There’s many ways to tackle these projects, and it really depends on, again, where you’re starting from and what your objectives are.

Ben May:

I think it’s also important to flag as well with WordPress, VIP that it’s more than just a straight lift and shift. When people talk site migrations and things like that. It can be at its easiest, zipping up an archive of code in a database, pushing that to another server, extracting it and then running again. VIPs is like a managed platform, and has a very particular set of configurations, so there’s no straight push from one system to another. Even at as easiest reconfiguring your application to leverage the platform that VIP provides, which has got all of its built-in functionality and things that come part out of the box.

But that definitely doesn’t just happen by just dropping a existing WordPress install on top of VIP. It needs to be integrated effectively, and to leverage all of those toolings. So, expectation setting again, that we still need to do some work, and there’s going to be… Even if we’re not changing a single thing and it’s a WordPress to WordPress, there’s still definitely some configuration and backend wiring and plumbing that needs to be done to make sure that both the site migration will be successful, and that you’re also leveraging VIP’s platform, which is probably one of the reasons you’re moving to VIP.

Enfys Book:

Yeah, one of the unfortunate surprises sometimes that happens is if the developers have not been involved in the sales process ahead of time, and maybe they didn’t even know they’re going to be migrating the site until suddenly it’s like, “Okay, we’re on WordPress VIP, make it happen.” Yeah. People who are accustomed to moving from one self-hosted WordPress to another self-hosted WordPress, like you said, fairly easy just to export the database. Because we really value such good version control and DevOps and want to make this scalable for enterprise use, people with tons and tons of employees working in the website. So, we have your plugins and themes are managed in GitHub, so it’s not something you’re just going and buying it from the WP admin. You literally need to download the plugin, get the latest version, commit it to GitHub, run it through the scanner, make sure it’s looking good.

There are things that people are often accustomed to using, like a WP all export plugin. Like you can export your site that way, but on VIP, we give you self-service tooling within the command line that you can import your content that way. So, they’re not super tricky things, but they may not be expected for people who have done a lot of WordPress migrations in the past. They’re all done for very good reason to make sure you can use this WordPress at scale, but sometimes that is a bit of an awakening for folks.

Yeah. I also want to say too, just based on my past experience, that when you are re-platforming a website, it is a fantastic opportunity to improve your user experience, your information architecture. It’s a good chance for spring-cleaning, especially if you haven’t done it in a few years, you might find, “Oh, wow, there’s some outdated information here.” “Oh, wow, we could really probably improve this functionality.” Or, “Oh, this plugin we’ve been using hasn’t been updated in three years. That’s not good.”

Go through and make sure you’re using the best things for your site, tidy it up, make sure that you’re not moving a bunch of old content you don’t need, you’re not discovering, “Oh, there’s a hundred gigabytes of video here.” That’s not great if you don’t need to self-host that. Maybe it’s not even being seen anywhere. So, I do encourage people to take the time to look through that. Yes, and for those who joined a little late, just want to let you know, please feel free to drop questions in the question box throughout. We hope to have time for questions at the end. So, let’s talk a little bit more about those technical issues to keep track of. So, there’s of course lots of things that can come up during the course of a migration. Francois, do you want to tell us a little bit about some of those issues you were tracking leading up to your VIP migration?

Francois Joubert:

Of course, two main themes, the one less technical, more around project management. As you’re going through these migrations, we had a very strict set of business objectives we wanted to meet, and one of those objectives broadly speaking was trying to leverage as much of the benefit that WP VIP would bring us. So, obviously you’re trying to do all of these things that you just described, doing the housekeeping, make sure you can actually leverage the platform once you’re in there. So, whenever somebody introduced additional scope, we really made sure to have a thorough scope conversation, and not just easily admitting any new scope into the project to make sure that, really look at the technical impacts of that when we bring that into the scope, apart from the timeline impacts that you would inevitably have, but we didn’t want to introduce any changes in our technical approach that would move us away from those business objectives, or move us away from really being able to leverage the platform going forward.

So, that’s the one area we really focused a lot on. The other area, very important for us, is SEO. So, again, we spent a very large amount of time with our SEO partners, understanding what is working really well at the moment, what’s not working well at the moment. Obviously, doing the typical comparisons with our competitors, really deep diving, Google Analytics, understanding exactly how Google views our website, so that when we did this transition again, we could do a little bit of that housekeeping, clean up the IA where we needed to, and make sure that our SEO impact is not only minimized, but we take a big step forward once we are on the new platform.

Ben May:

I think…

Enfys Book:

Absolutely, go ahead.

Ben May:

Yeah, I was going to say it’s good to establish as well, I think most of the sites we’re talking about moving to VIP. We’re not talking about local cupcake stores six page website. We’re usually talking about more enterprise, high-end complex sites, and in my experience having done it for a while is that rarely the teams, or most of the people involved in the migrations were there when parts or parts or all of these sites were built. As a general rule, sometimes you’re surprised, and you’re working with a team who was there when it was built, and they know where all the skeletons are thing. So, it’s this concept of how auditing a site, but really being deep on that audit and understanding, what are the hacks we’ve had to build in the years gone by that we had to do in a short time, and the tech debt that accumulated throughout the site. Moving anywhere, moving from one infrastructure to another regardless of even VIP is a good way to shake that out.

But definitely moving to somewhere like VIP where you have a lot of rules and automations around code scanning and code standards, especially in the WordPress ecosystem, gives an additional dimension to shaking all of those cobwebs out of that old application. That’s one of the biggest risks we see of, “Oh, we realized that this certain feature had been buried away in a bit of code for a long time, and for whatever reason it just never worked. Maybe it was getting blocked at someone had done it in a DevOps capacity on AWS, and now that it’s live on VIP and working how WordPress normally works, something just came to life and started doing something,” and that happens more often than not. So, by understanding that there’s a certain limit, you can do discovery till the end of time and still miss things, but also making sure that an appropriate amount of time and comfort around the application layer is familiarized with everyone involved in the project.

Enfys Book:

Definitely. One of my recommendations is, like I said before, bringing in the development team and also your IT team into the conversations early. So, as you are looking at doing the migration, it’s important to know what your IT department’s policies are when it comes to SSL or TLS encryption, access provisioning, if you have certain policies and standards around that. If you have to use a reverse proxy for example, sometimes that’s defined by what the URL of the site is going to be, but perhaps there is a policy that requires it. It’s good to know all of that ahead of time because there are implications for how you set up the site from that, and they can add additional time to your migration. For example, reverse proxies are one of those single points of failure I do see fairly often because in order to get a reverse proxy to work, you have to do a little bit of extra code within VIP.

We have documentation that’s pretty clear about that, but I always tell people build in a couple weeks of testing that proxy configuration before you launch, just to make sure you’ve figured out all the bits on your side, all the things that have to happen on the VIP side to make that work. When it’s well tested, it tends to go very smoothly. But if people realize that on launch day that is part of how they are pointing their domain to us, that can cause some last minute problems. It’s also useful to look at your dev team, or the people who you expect will be moving the site over, and see if there’s bandwidth to do the migration on top of everything else that they have to do every day, or if maybe it would be really beneficial to bring in an agency, like for example, the Code Company to help people who have lots of experience moving websites onto WordPress VIP, people who know all the little gotchas and things that can cause issues down the line.

It’s really helpful to have a partner to do that, especially if your team is small, or if they’re already overwhelmed with just keeping the site going. The great thing about bringing stuff to VIP is if you have been managing your own servers or your own security updates and things like that for WordPress core, VIP does that for you. We take care of the architecture, we take care of WordPress core updates, Jet Pack updates, things like that. But in that process to get that to go smoothly, you want to make sure that you have the bandwidth that you’ve accounted for, all of the pieces of functionality that have to move over, seeing if there’s anything that’s incompatible. There aren’t many incompatibilities, but once in a while there’s something that comes up in the course of migration, and it’s better to know ahead of time. So, yeah, it’s also a great chance to see what you already have, looking into your image optimization, maybe cleaning that export data a bit, things like that to make the site new and shiny and wonderful.

Ben May:

I was going to add as well, just in terms of the types of developers, I think there’s a question about the talent on one of these projects, and I think the observation I’ve had doing a few of these is, in terms of an engineering team that is going to be largely responsible for the technical component of the migration, I think is a mindset around buying into the values that someone like VIP provides. First of all, there’s a lot of development teams and DevOps teams we work with who will always think they can build it themselves better, and be stuck with that forever on. So, I think it’s a much harder quality to establish, but people who actually believe in the benefit of why you would be moving an application to a platform such as VIP, I think that conceptual hurdle jumping that, first of all, is going to make things a lot easier and realize… Because otherwise, every time you find a constraint, you can either say, “There’s a reason there’s a constraint and we can leverage this constraint to de-risk how we operate our WordPress environments.”

Or, every time you hit a constraint, you can be angry and say, “Well, I could do this myself in AWS, and I could write a bit of node.js and do this myself because VIP is locked down,” and that mental barrier, I think if you’ve got the right attitude to begin with, a lot of those navigations become a lot easier and realize, “Yeah, that’s a little bit frustrating, but if I work it this way, it’s still going to achieve the same result, and I know it’s best practice, or it’s all living in the WordPress ecosystem. I’m not the slowly building another Frankenstein,” which probably is why you’re migrating to begin with is because you’re already operating Frankenstein’s tech stack with a hundred little bits and pieces that keep it all alive, and no one really truly knows how it works.

Enfys Book:

Very true. I thought maybe we could dig a little more into… I was being general talking about, “You need developers to work on this,” what technical skills and what people need to be involved in actually moving the website. I thought maybe Ben, you could talk about folks on your team. When you have one of these assignments, who all do you have in terms of background and skillset working on it?

Ben May:

Yeah, so I think first of all, we are all pretty unified skills, attitude in terms of the value and that hurdle being jumped, so that’s good. We don’t build our own DevOps for that exact reason. I think that the biggest ones that jump out, especially for the kinds of sites we work on, where we might be moving terabytes of media assets, or millions of articles and millions and millions of comments, and hundreds and thousands of users, and these large scale sites.

For us, it’s definitely people who have had more experience in high scale, high performance, understanding the impact of doing a meta query, or select, or that level of detail, especially when you scale out. Leveraging VIP makes things a lot easier because of the containerized platform, and we’ve had really good success with that. So, yeah, definitely for the migration and configuring, or reconfiguring an application to leverage VIPs, definitely a more full stack and a lot of backend, PHP-based skills that are going to take advantage of that. More on the front end and UX UI component of a team is only as relevant, depending on how much you’re looking to change things up in that migration.

At the simplest, someone who’s going to better understand database exports, migrations. Sometimes we’ll do a migration to VIP and that will be the ideal time to look at doing a multi-tenant WordPress multi-site approach. So, that is definitely going to save and simplify the code base, and operational cost going forward, but a migration into a multi-site definitely have some nuance when you’re looking at things like mapping, merging user tables and updating records, and things like that. So, yeah, you’re definitely going to need to work with some more senior backend database engineers that can understand that part. But once you get past that hurdle and you’re on the platform, the requirements become significantly simpler, and general development teams that work in more modern enterprise business-grade environments will usually pick that up pretty quickly.

Enfys Book:

It really helps to have people working on the migration who are very familiar with, and comfortable with GitHub, people who are comfortable working in a command line, because a lot of how you interact with your application will be through the VIP CLI, for example. When you’re doing imports, if you want to change specific things about the site, a lot of that happens through there. But yeah, once the site is up and running, one of the great things about WordPress is that it’s easy to use, it’s easy for your content editors to make updates. There’s a lot of different ways you can customize it to build in approval workflows, and things like that. So, yeah, there’s just a lot that can be done there. Francois, I’m curious, who did you have involved on your side when you were doing the migration? What skill sets and roles did you have?

Francois Joubert:

To Ben’s point, it’s quite a mixed skill, in a way, as well. So, it really depends on what you’re dealing with. So, we had skills from our normal development side that looks after the rest of the website, so to speak. The non WordPress portions, because you have all these integrations that you need to deal with in an enterprise architecture. So, we had representation from that teams, we had our DevOps guys involved, obviously, all the typical networking and security aspects, and code repos and so forth. Most importantly, you need those people that’s used to working with software that’s called Enterprise Grade that’s familiar with what this looks like at scale, and also what it looks like when you’re migrating at scale or doing anything at scale.

There’s a vast difference between a small website and one that is highly trafficked, highly popular, too. There’s just so much more that you need to worry about and think about. I think in our case, we really worked very closely with our SEO partners to make sure that there’s no impact on SEO performance at the end of the day, because of where RE/MAX is currently rated in the industry, how much news traffic we get, we definitely want to make sure we don’t impact any of those aspects.

Enfys Book:

Yeah, absolutely. Let’s go back to the why, a bit. Why do people migrate to WordPress VIP? Ben, you were talking about taking advantage of some of the ways in which VIP is set up. Can you elaborate on that?

Ben May:

Yeah, I think there’s a couple of main reasons we will bring that conversation up with people we work with. I think, definitely, the package of tools that come out of the box with VIP, so things like baked-in Elasticsearch, or baked-in image manipulation services, and things like this, definitely simplify even vendor management, in a medium or larger sized business. Instead of having, we have an external elastic provider, an external image service, and we have a different CDN provider, and an infrastructure provider and an DevOps layer on top. It definitely simplifies that stack, and this is a stack, it ticks a lot of boxes for a lot of applications. Anything in technology, there’s not a single option that’s always going to tick every box for every person, but VIP is a really compelling mix of things that people are looking for, and provides a lot of value there.

Apart from that, and that’s management style things, but is we’ve also found just the subject matter expert part of this, and a lot of businesses that we work with, they may have a bit of a development team or things like that, but they don’t necessarily need to have a full infrastructure DevOps team. So, being able to lean on VIP to manage that whole layer, because anyone can read a tutorial and set up a digital lotion account and set a WordPress site up and run, but then when they leave the business, and no one knows how it works or how it runs or anything along those lines is an incredibly common problem that people have or some obscure AWS account that’s locked to someone’s private keys that have left the business, or these kinds of things.

So, for us, going back to even the constraints, and I’ll often, when I’m talking to execs or business people, I’ll say, “Your devs will probably be a bit frustrated. They’re going to lose some access to things they’ve worked with before, but they’re not going to be here forever. If they have to leave the business or you bring in a new team, this is as close as you get with WordPress in terms of industry standards about the platform, and having a bit of continuity knowing that you could bring in new developers, a different agency, you might want to switch out an agency to another, you’re going to have this continuity between teams and people and things like that.”

Francois Joubert:

That’s quite interesting though. You’ve mentioned in this point and the previous point, around some of the constraints that developers tend to be frustrated with in this space, and from our perspective at least, these constraints were actually very appealing to me. What I was really after was, I was looking for that best of breed implementation of WordPress, have it really, really standardized, and have it as a managed service so that there are fewer moving parts, and there are fewer places where people can customize or change it, or a developer can freely access certain parts of the application to change it in a different direction. So, we really wanted to have that control around our environment, having everything as a managed service. To your earlier point, again, having all those ancillary services available inside of the platform just simplifies life so much, and it just makes the day-to-day operation of the platform a lot easier and a lot less time-consuming, so you can focus on other areas of your business that requires that type of attention.

I think the other big part for us at least was we have a really high security standard that we trying to adhere to, and the WordPress VIP environment is extremely secure. It’s well-documented. All industry standards audited continuously, and it meets every vendor out there’s requirements whether you financial services, or real estate or marketing space, whatever industry, it’ll meet that security standard that you need to be at. That, again, was very appealing to me.

Enfys Book:

Yeah, some examples of that security are that we are FedRAMP certified and also GDPR-certified, and one of the things we require of how we set up the WordPress admin is that anyone with access to make any change to the site has to be using multifactor authentication to get in, that has to be enabled. So, it’s one way that you make sure your site is secure from somebody having a really poor password, for example, and so on. So, it’s really nice to have that peace of mind.

Ben May:

Anytime we’ve been brought in by a marketing team or something like that, that in a business similar to RE/MAX where WordPress is a smaller piece of the overall infrastructure, like, we will come across a Francois, like a CTO, a CIO, someone who has to ultimately sign off, they don’t want to be dealing with WordPress, they’ve got a much bigger internal team that’s dealing with the actual product and their actual business. The WordPress piece is usually to give a marketing team, or content, or whatever that may be autonomy just to do their job and not complain that they’re trying to get access to internal resources and all this kinds of things. So, WordPress enables, like we were saying before, the autonomy for users to do their own stuff. So, for when we can go to a CTO/CIO whatever and say, “Here’s the VIP platform, here’s all the boxes it ticks.”

As long as they know they’re not going to have to wake up to a hacked WordPress, most of the meetings I have is like, “I just don’t want it to ever backfire. I want it to work, and I don’t want to have to think about it, and I can focus on the bigger part of our business, which is building our product to do X, Y, Z.” That’s one of the biggest reasons I think why we will see people move across to something like WordPress VIP.

Enfys Book:

Yeah, absolutely. Francois, did you have something to add?

Francois Joubert:

No, I think Ben captured as well, right? The support of the business that we just wanted to work and work in a predictable way, and have great security and perfect uptime and WordPress VIP provides that for you. In our case, I’ve got the rest of the website where listings are, and it’s obviously very business critical as well, but WordPress is a substantial part of the business because of the blog and are standing in the news industry. So, it is probably just as critical as the rest of my stack, but because it’s on WordPress VIP, it requires a substantial amount less of my time, and of my team’s time. It really gives that autonomy to my business teams to run with it. We’ve given them a great set of tools. It is best of breed in the industry and they can do everything they need to do, and all the fundamental technology processes, security, DevOps, maintenance, all of that’s just taken care of for you. So, in my mind, that’s a really nice value proposition.

Enfys Book:

Thank you. I’m blushing over here. I take some pride with the place I work. This is great here. Let’s talk a little bit more about those benefits and what tools or resources we have on WordPress VIP. I just want to throw out some of my favorites real quick. So, we have this really great web-based self launch tool, which has been a thing since I joined three years ago. This was just becoming a thing then, and if you can walk through an installation wizard on a Windows machine and click next a bunch of times, you can launch your website. It’s very easy to use. It is just point and click, very simple controls to get… The tasks of launching your website on WordPress can be a little bit different from some other CMSs. For example, it stores the entire URL from beginning to end throughout the database, so it’s not all relative URLs that start with a slash.

So, to that end, when you launch, you need to completely find and replace all instances of whatever convenience URL you’re using. You also need to set the home and site URL, and all three of those things that search and replace, set home, set site URL, that’s one button click with our self launch tool, which I think is really cool. It gives you your DNS instructions so you know how to point your traffic toward VIP, and you can provision your TLS certificate right there in the dashboard. That’s probably my favorite thing. I also love that we have self-service data imports and media imports through our command line interface. I think that’s really cool that we can get out of customer’s way, in that way, and just let them have the freedom to develop their site, import their content. Sometimes I kick off a customer, and I hear nothing from them until they launch because they’re just good to go and they could do most of it themselves, so that’s always a really a great thing. How about either of you? What do you have thoughts on some of the tools and resources?

Ben May:

I can go and say, I think yeah, definitely having some autonomy. I know our team, especially when we’re working in Australian timezone, and we’ve still got VIP support in our time, but there’s definitely a lot bigger team in the US, so having that autonomy any day of the week, anytime, is definitely appreciated, makes things a lot easier. I think conceptually though, it’s understanding that VIP, it’s an entire ecosystem. It’s not actually just C panel hosting or an EC2 that we’re just dropping some code on, and thinking about it that holistically about from how we use images and how templates are built through to plugins and their configuration and things like that. I think once you grasp that it’s more than just a platform. It’s that whole ecosystem of ancillary pieces. It helps you understand how to build your application to take advantage of all of those things, and that’s where the documentation and the support team and everyone involved is very helpful for that reason.

Enfys Book:

Yeah, we also acquired Parsley Analytics last year, so we have really tight integration with their fantastic analytics platform, which I know a lot of content managers and strategists really appreciate. So, that’s one of the things I’m also excited about. Francois, what really drew you? You talked about the security before. Are there other specific features or tools that you found really helpful for your migration?

Francois Joubert:

Documentation is great. That’s complete. I do like reading the manual before… The support team, they have deep knowledge of the product. So, whenever we had something that we didn’t understand, or we were wondering about, we got really good advice in that aspect, and I think the entire ecosystem is well-defined, and really self-service. So, you don’t need to read the manual, you don’t need to ask all the questions from the support team. You can self help, you can do it yourself, which is nice when you have that entire ecosystem that is so well integrated, and works so well together, it makes fewer moving parts. It makes life a lot simpler to maintain and run the application at a really high standard.

Ben May:

One other little thing to add is actually, just to double down on that, is actually the people in the support side of things, and unlike any provider we’ve worked with, VIP is that unique position of, if you’ve got a developer or someone maybe less senior involved and there’s a particular function in a plugin or a theme, they’ll be able to actually jump in, usually and help to line-by-line support of application, and that nuance of WordPress. One of the challenges, generally, with WordPress is that there’s no certification. There is no way for a buyer to understand who knows what they’re talking about with WordPress.

There’s no difference between someone who’s done 10,000 hours or two hours, they can both say the same things. So, it definitely helps, knowing that VIP has a team that has generally in the tech side, a very long tenure with WordPress, and understands a lot of these paper cuts that come with any open source system. But it’s the closest thing I would say to people of having that WordPress certification of talent and support and people like that who have done this before, or if not the person you’re talking to, definitely someone in the VIP team to support your team, leveraging WordPress to the best it can be.

Enfys Book:

Absolutely. Now we’re getting tight on time, so I just want to run through some takeaways before we shift to questions. Folks, if you have questions, please pop them into that questions box. That would be great. We’ll have a few minutes for those. So, some of the takeaways of stuff we talked about early on, of course, clearly identify your business objectives for your migration at the beginning. Make sure everybody is clear on that. Plan for the unexpected, don’t make assumptions. Francois’s favorite, read the manual.

One of the really cool things too is that when Francois moved the RE/MAX site over, they had already gone through and audited all their plugins to see which ones needed to be updated, which ones were duplicative. If there’s existing security plugins, those are not necessarily needed on VIP, because we have a lot of baked-in security, things like that. The more you prepare and audit what you’ve done, the better, the smoother it’s going to go. Yeah, we talked about continuous improvement, we talked about the importance of thorough testing. We definitely can say lots and lots of testing is good for any time you’re moving a site. Yeah. Anyone have other key takeaways they wanted to add here?

Ben May:

I think it’s just about realistic expectations. These are usually big, hard projects to do. Rarely is perfection ever going to be. You get 80/20 rule of how much expectations versus being a hundred percent perfect. So, as long as there’s an honest culture of rapid innovation, and jumping on things that will inevitably happen. If you’re using a site with 5 million URLs, no one’s going to be able to click through every one of those URLs, and test the site. So, it’s always about being strategic about these things.

Enfys Book:

Absolutely.

Francois Joubert:

All right.

Enfys Book:

Wow.

Francois Joubert:

Yeah, no, no, I think that continuous delivery, continuous improvement approach is really good, especially when you have large migrations. Don’t go big bang. Don’t think you’re going to get perfect the first time and go with everything at once. If you can move it with the MVP first, and then iterate from there, that’s always a good approach and at least you start getting that business value sooner rather than later.

Enfys Book:

So, we do have a few questions coming in. I’m going to throw this one out to the two of you. What are considerations for migrating a site in multiple languages, considerations for accessibility, adding or improving compliance? That’s a nice juicy question there.

Francois Joubert:

[inaudible 00:48:17]

Ben May:

Otherwise, I can give it a go. I think the first thing I always understand about those sorts of migrations is how has it been done, currently? If you’re moving a site that has these variations, and the biggest thing, is it already in WordPress or if it’s not in WordPress, it’s understanding how do you migrate that data into a WordPress-friendly version of like a WPML, or some multilingual plugin. There’s different degrees of intensity of doing multilingual sites from English as the base, and then auto variations of everything else on top of that, through to custom Bespoke translations. That’s becoming more challenging, with the introduction of the block editor and being able to build much more richer layouts now, as well. One of the common ones we see with people when they do multilingual is the amount of times, and people don’t really think they do it, but it’s surprising how much they do it is adding English language into images, like for screenshots of products and things like that, and it’s like that throws another whole set of different challenges.

So, understanding, from a baseline, if you’re starting from purely an English site, and you’re moving out to additional languages or other way around, how many little paper cuts like that are going to be out there, I think it would be worth selecting, based on the requirements, how you’re going to do the language in WordPress. So, there’s a half a dozen different plugins that do that. You can do a more manual approach through WordPress multi-site, understand that architecture and then how do you migrate into that ecosystem, is how I would start thinking about that.

Francois Joubert:

Whenever you go multi-language, or you go accessibility, it’s really important. I think if you look at everything beginning to end. I’ve said this a couple of times, doing that audit to understand what you actually have, and look at it specifically with that lens, because you think you know how much English you’ve gotten. “Oh yeah, we just have to apply dictionary, and this piece will have to custom write,” and then you go do the audit, and the list is longer than your arm. Really what it helps you to do is start thinking about how you can actually maintain this in the future. Now, it’s easygoing one language or two, but when you have 10 languages, that lift of putting any new piece of content out, or any new piece of functionality, if you haven’t really designed for it, and designed with a view of how you’re going to maintain this and sustain it, in the long term without building a team of a hundred translators, that’s really, really important to think about that upfront.

Enfys Book:

Yeah, I’ve seen a lot of different ways people approach this. There are some popular translation or multilingual plugins that people use. Some of them require you to have a multi-site in order for it to work. It basically creates a sub-site for each language. Some of them don’t. The mechanisms they use for translation can vary. So, I think if it’s you’re bringing a site into multilingual for the first time, evaluating those different plugins and seeing which one is one that meets your requirements, and making sure that it’s frequently updated and well-used in the WordPress community as always a good idea, and the same for accessibility.

There are certainly ways that you can approach that from a lot of different angles, if you’re concerned with 508 compliance in the US, for example, there are some fantastic consultants who can evaluate your whole site. There are also lots of automated tools that can go through and do that for you. It really depends on the size of your site, and what your actual requirements are at your organization. Yeah, there’s a lot of different things to consider. That could be a whole other webinar. So, yeah, let me see what else we have for questions. We also have, “Are there any specific challenges going from HubSpot to WordPress, when migrating a site?” I have not personally done a migration like that. Ben, I’m not sure if you have?

Ben May:

I think we got involved in one a while ago, and it wasn’t pretty unfortunately, I don’t think… This is pushing it a year or two ago now, but HubSpot didn’t give a very friendly way to export content. There was a lot of manual labor involved in that migration, and that’s a general challenge with any SaaS product. We’re talking to someone at the moment about a Squarespace, a corporate site, they’re moving into WordPress, and it’s like just on the outset it’s going to be a pretty rough migration, because you don’t have access to raw data, and that’s one of our general open source principles of why we like open source, that you own your own data. If you want to move to Drupal or you want to move to Side Court in the future, you own your data, you can do it whatever you want with it.

You’re not going to be copy and pasting. So, HubSpot, I think that, unless something’s changed or potentially they give access at a higher tier, maybe, it is accessing the data, accessing how, and then mapping that into a WordPress ecosystem to clean that data up. Then the usual principles of data migrations of how good is that content? We’ve done migrations with 20 year old CMSs, and you can always tell as they’ve released different versions of their own CMS, like how data is stored. So, you’ve got to build a migration tool that understands like, “Oh yeah, we need to strip tables, and convert this and update that and remove inline CSS, and how much data scrubbing do we really want to do.”

Enfys Book:

Yeah, my previous job to this one, I was cleaning up content that was being automatically pulled in from somewhere into a CMS, and going through and seeing how much garbage HTML got added. I had a number of macros on Notepad++ that cleaned stuff up really quickly. But yeah, it is worth keeping an eye on that. “What are some signs to look for to consider migrating, and what is your number one piece of advice for someone about to start the process?” Let’s take that second one first. What’s your number one piece of advice for someone about to start migrating?

Francois Joubert:

Always start with business objectives. Why are we migrating in the first place? What business value are we trying to unlock? I think if you have that, that is your North Star, that helps you make a lot of decisions easier, it helps you manage scope, it helps you manage timelines. I think it keeps the whole team on the same path, if it’s very well-defined. If it’s not, then a lot of stuff tends to creep in, and you end up with an architecture that’s not as pure or compromises… Well, that are compromises instead of really understanding what the best solution was for that particular situation.

Ben May:

Yeah, I think the same thing, and the advantage of what that does is it just automatically sets expectations. If one team thinks a migration is going to all of a sudden fixed conversion rates by 20%, the people who are actually doing that migration will be like, “Hang on, that’s got nothing to do with it. This is a technology or we’re doing this for infrastructure, or security, or whatever.” It teases that out really quickly, so you don’t get to the end of this project, and the investment’s made and you’ve done everything and then some magical thing never happened because no one ever thought it was going to happen. It teases that out really quickly and avoids uncomfortable conversations later on.

Enfys Book:

Yeah, I think for me, it would be have a good sense of your scope that ties in with the business objective’s thing, but have a good sense of what you want to accomplish with the migration and what you are going to wait for future iterations. Have a sense of a minimally viable product when you migrate, “What is the bare minimum that we want to be successful in this migration and what can we add onto after that?” I think having that sense of scope will help drive decisions, and it wouldn’t hurt to make up a RACI matrix as well, so who all is responsible for different aspects, who needs to be consulted, and so on. Especially so you don’t give someone an unpleasant surprise on launch day like, “Oh, I didn’t know I had to do that today,” so that would be my recommendation. Just checking for other questions here.

Ben May:

The first part of that question about the signs of migrating, I think the ones we usually see where people, it comes from a couple of different angles as like Francois was saying about that outsourcing of that part of governance of the WordPress stack, there’s definitely that angle. We also see people in digital media who will be scaling and growing. The last two years have accelerated a lot of digital media growth, so sites have increased in speed and page views, and the infrastructure knock-on’s.

We’ve just recently done a migration from a publisher that was running on an old physical server in a data center somewhere, and they just were slowly, slowly… This server just couldn’t have any more things added to it to keep it alive, and they were pushing 10, 20, 30 million page views a month now and that infrastructure, if you could call it that, was just not keeping up. One of the things we saw literally within two days, so not overnight, maybe, because Google is a bit slow to do this, but the in search console, the response time dropped. It was just slowly creeping up over six months from 400 milliseconds to seconds, basically dropped off a cliff back down to like two, 300 milliseconds as a response time. So, we instantly saw overnight moving to more appropriate infrastructure, just completely brought the site’s performance back to life.

Enfys Book:

Yeah, I think the number one reason I hear people migrating, and what they want to get out of specifically moving to WordPress, is they want their marketing team to be more agile, and be able to update content easier than if they’re not on something that is as user-friendly as WordPress. I weep for the people who cannot make an update to the website without going through, like somebody raw-coding it into the site is the only way they can actually make updates. If your website’s built on cold fusion or something, it might be time to look and see about migrating over. If you are on a technology that is no longer supported, that is a very good time to migrate. Great. Well, I think we can wrap it up there today unless anyone has some final thoughts.

Ben May:

I think I’ve made my point very clear, so it’s been great.

Enfys Book:

This has been great. Thanks everyone so much for attending, and yeah, have a great rest of your day.

Francois Joubert:

Thanks everyone.

Ben May:

Bye.