CMS Content Migration: An Unavoidable Headache

p>Having done CMS implementations for years now, I’ve noticed that there’s one part of any given project that always seems to frustrate both the client and the agency without fail. That’s the area of content migration.

For the purposes of this post, we’ll define “content migration” simply as the porting of content from your old content management system to a new one.

Migration is a pesky subject that is almost universally underestimated by the client—and sometimes by the agency. It’s a task that is made more difficult by a variety of factors both incidental and deliberate. And it’s the number one reason why implementation projects can go beyond their intended schedules.

Content is the lifeblood of your company’s digital presence. Depending on your industry, your content can be the largest asset your company has. For news or media organizations, you’ve most likely spent millions of dollars producing this valuable commodity. For e-commerce organizations, the content is what drives all of your sales. Yet with CMS projects, it’s too easy—and unfortunately all too common—for people to forget this fact. It’s almost like they don’t realize they are showing a level of irreverence to the very asset that keeps them in business.

Let there be no mistake: Content migration is one of the most important parts of your project, and it can also be one of its most difficult and expensive components. You need to take this seriously from the first day you even start contemplating your initiative.

The purpose of this post is to shed light on why content migration is a such problem, what makes it so difficult, and how you can prepare and plan ahead to make sure your next migration goes as smoothly as is possible. There are tricks you can do, tips that will help, and there are most certainly certain platforms that are better than others in terms of “content portability.”

Let’s start with the origin of the headache.

The Problem

Content is important. Your site obviously can’t live without it. Yet so many content management systems do a terrible job at actually managing it.

Isn’t that weird? How can a system designed to manage content store it so poorly?

The biggest reason migration is a challenge is because the originating system manages content in a shoddy fashion. This can be due to a variety of internal reasons. Maybe it’s an obscure, archaic CMS architecture that stores content in a way that makes accessing the raw data very difficult. Or maybe the CMS vendor has made it difficult for a reason, hoping to handcuff customers into their solution for years to come by making it difficult to escape. Or even worse, maybe it was, in fact, a great system that was poorly implemented when it was first provisioned. I’ll dig into the why a bit more in the next section.

Either way, almost every platform-to-platform migration has some horror stories.

Many solutions in place today try to automate this process. There are providers that can now “migrate” content from one system to another for a one-time fee. These providers offer a simple, self-service model where you choose the CMS you are using and the CMS you are moving to, and they automate the transition.

The problem is, almost no transition ever works perfectly without a manual component. Just because the data is moved from one data storage mechanism to another doesn’t mean it is organized in a manner that is helpful or even usable. In many ways, it’s better to do as much of the work manually as possible, provided you don’t have so much content that this isn’t a feasible approach.

Of course, if there was some sort of universal standard, this would be so much easier, right?

Maybe. But you have to also remember that every implementation is unique. Each project has hundreds of choices that the content editors and implementation team must make. Even with a universal standard, would this problem really go away?

Migration is often a massive headache, and will remain so for the foreseeable future.

Why Is It Such a Headache?

As I mentioned earlier, there is a plethora of different reasons that systems have poor data migration capabilities. The first is honest and simple: poor architecture on the part of the originating CMS.

I remember doing a CMS transition from a system powered by text files. Each piece of content lived in its own text file, and to migrate it was nearly impossible. We had to create manual scripts to open each file, absorb the content, and put it into a portable format. The amount of time to create the script alone cost the client thousands of dollars.

Now, this wasn’t a malicious act by the original CMS vendor. They were just happy that their CMS offered a speedy delivery of content that was also scalable. They accomplished this by offering flat text files (sort of a precursor to today’s NoSQL solutions…sort of), and those files all existed on the server in different locations. The developer in me appreciates this approach, and that’s why I call this an honest or simple mistake.

The customer, of course, had no idea—they were simply impressed by the speed of delivery. But when the relationship with this vendor went sour (as many vendor relationships do), they shopped around for other solutions and found us.

It wasn’t a complex job. There was a fairly rudimentary content model and a simple enough front-end design accompanying it. But the migration still became a disaster for both us, the agency, and the client. The original CMS vendor didn’t play ball with our transition plans, not offering any help other than providing access to the code. I was happy to acquire even that level of access.

Imagine our reaction when we discovered there was no database to be seen! The transition eventually was figured out—there is almost always a technical solution—but not until after significant workarounds were put into place that ended up costing the client time and money.

Another example of a difficult migration is when a CMS vendor has the content stored in an illogical way. This primarily occurs when a system forces a user into a particular content model. Exporting content from this type of platform into any other system is difficult given the proprietary nature of how the content was stored originally. In cases such as this, the migration of content involves a heavy refactoring component, which is basically the reorganization of content before being ported into the new destination system.

The most frustrating example of a migration disaster is when you have to migrate from one platform to the SAME platform, yet it isn’t easy because the original implementer did a less-than-stellar job of implementation to begin with.

A CMS is only as good as the person who is provisioning it. Just because you’re moving your site from Drupal to Drupal, doesn’t mean it will go smoothly. Much like anything else, it’s garbage in, garbage out. And it can be very frustrating for a client who just wants to redesign their site to be told that they need to also re-implement their entire CMS because it was either set up poorly in the first place or accrued loads of technical debt (both in the platform and in the content) over the years.

The “CMS cycle” is primarily driven by scenarios where the technical debt of a system or the content within requires a rebuild every couple of years.

This is easily avoidable, but only if you know to avoid it.

In some of these cases, again, you can almost forgive the original CMS vendors—it’s bad practice, but their intentions were probably good. But truly, the worst is when you have CMS vendors who deliberately make it difficult to migrate off of their platform.

Sure, in a demo, a sales person may tell you how easy it is to migrate off of their platform. But in reality, many vendors work to make it difficult to leave, and they do it on purpose. Of course, no vendor would ever admit to this, but it is most surely a real business model. This problem exists much more with either proprietary, closed-source systems or heavily customized systems that are maintained by an agency. Since those companies have an interest in recurring license fees, it does not make sense for them to make it easy to leave them.

How to Avoid Future Migration Hassles

Many investors in both real estate and stocks know that you profit when you buy, not when you sell. This is because investors are trying to find as much value via proper due diligence when buying an investment vehicle as opposed to buying and then hoping for the best while sitting tight.

The same applies to a CMS selection process. You will determine how easy migrating away from a platform is when you procure it.

During the sales or discovery process, ask about migration-specific topics. Here is a quick list:

• Export Capability—Asking about future portability is important. Is exportation possible? What formats are supported? Can we see this in action? Can we see sample data that is output? All of these questions will result in your ability to judge the capabilities of the platform for future migration. Again, plan your migration before you ink the deal. It’ll save you a lot of hassle in the years to come.
   
• CMS Architecture—How is the CMS architected? Was the CMS originally built for one purpose and then expanded upon, yet retained that architecture? That may be a problem in the future. Is it headless, storing all data cleanly in content models you define or rather, is the system coupled and storing data as they defined? Asking these questions will give you a sense of your flexibility in the future.
   
• Examples—Can you provide case studies or examples of people who have left? I know, that’s a crazy question. And most likely, whoever you are talking to, whether it be a sales person or implementer, will not have anything to show you. But just asking the question and judging the response will give you some insight.

Interestingly, more and more CMS projects and vendors are offering migration services or software to move ONTO their platforms. It seems that this is yet another area of opportunity to monetize on the frustrations of customers. We’ll see how that progresses in the future, but for now, we stand by the fact that all migrations still offer some level of manual intervention. When presented with migration options TO the platform, it’s a great time to ask about how you can eventually LEAVE, too!                    

Finally, the best way to prepare for future migration hassles is to simply know they exist. Most likely, even the smoothest migration will have some turbulence. Luckily, this isn’t something you have to do often (hopefully).

How to Plan for Migration

Planning for migration is something that you, the client, probably will think of last. And that’s understandable—it’s easy to be distracted by the fun of a new web design or a new CMS implementation.

Hopefully, your implementer brings this topic up early and often (if not, find a new partner!), and you can be aware of the process of migration early in your budgeting and planning. In fact, I think all implementation agencies should have a separate line item for migration. And they should spend time during the discovery or planning phases to outline what their process for migration (and the costs) will be prior to being awarded the work. This would settle much of the vendor/client stress that could come later.

For you, the client, planning begins with acknowledging the problem. With that out of the way, there is much you can do to prepare.

First and foremost, do an internal content audit. Isolate your content into “migration” groups. Some content is “templatized,” such as news stories or blog posts. Those items can, in most cases, be automated for migration in many ways. Other pages such as homepages or product detail pages may have a more customized component. Begin by splitting out what can easily be automated and what pages may need a manual component.

As you go through this process, try to consider if the content you are auditing actually still has a purpose. Do you really need to migrate content from many years ago? Maybe yes, maybe no—and you should consult with your SEO strategist before deleting tons of content.

Going through this exercise will give the vendor or implementer a head start in terms of understanding what content is going where, and what template falls into what category in terms of difficulty. With this information, your partner should be able to better estimate the requirements and eventual migration pathways that will work best for your project.

As I alluded to before, make sure you are very clear on the migration costs and methodology from your partner or vendor. In some cases, content migration can cost more than the entire CMS implementation. If your agency partner says something like “it’s included” or “we’ll take care of it,” ask for more details about how they will do it and what their estimated timeframes are.

Trust me, you’ll be doing both parties a big favor.

The Migration Itself

The process of migration is worthy of its own long post, which I will definitely add to this blog at a future date. But for the purposes of illustrating how a migration works, I want to provide you with a brief outline, which will help you during your own CMS migration process.

Step 1: Export

This sounds easy, right? Click the “export” button and be on your way? The fact is, most CMS platforms have no such capability. And for those that do, you have no idea what is going to come out on the other side. Exporting data can happen any number of ways, but it isn’t ever as simple or as cut and dry as you’d prefer.

Step 2: Refactor

I call this “refactoring,” which is theft of a term we normally use in programming. Other words can be normalization, conversion, or transformation. Whatever word you use, it all means the same thing: taking your exported data and massaging it to be compatible with your new platform. Typically, this is accomplished either via a human being manually doing the work or via automated scripts that have to be developed specifically for this purpose.

Step 3: Import

This is another self-explanatory concept, but it’s never easy either. Once the data is out, cleaned up, and prepped, it has to go into the new platform. How difficult or simple this task is depends on the new platform. Hopefully, you choose wisely and this will be a simple enough task. But there are never any guarantees!

Again, while these steps are simplified, all migrations take this level of effort to complete. They are a process, and are best considered a sub-project within the entire initiative.

Conclusion

Content migration is a hefty undertaking, and yet it’s so often overlooked.

I guess the best analogy would be buying a new house or getting a new apartment. It starts with a recognition that for some reason, you need to move. From there, you research your options: buy or rent (much like CMSs!), house or apartment. Then you debate size, features, bathrooms, and bedrooms. Finally, after weighing all your options, you decide on your direction and pick a new home.

I’ve been through that more times than I care to admit. The first house I bought was a Victorian that was built in 1904. They featured very narrow staircases. When I was moving, I realized I couldn’t get my couch up to where it had to go. It wouldn’t fit. My options? Well, I could disassemble it (not feasible), try the other stairway (still tight), or dump it (ugh!).

Therein lies the challenge of content migration. It catches you by surprise, when you least expect it, unless you planned ahead for all of these possible scenarios.

Sometimes, it’s hard to know what you don’t know. You don’t do these types of projects regularly, after all. So, lean on your implementation expert to guide you along the way.

Trust me—you don’t want to throw out your favorite couch because you were unprepared.