Reading Time: 10 minutes

Every CMS implementation is different, but you can generally categorize them into two major groups, regardless of the details: New site or Lift ‘n Shift. If you’re unfamiliar with the phrase “Lift and Shift”, it’s where we take an existing website, in its entirety, and move it into a CMS without modifying any front-end code. The untrained and uninitiated sometimes call this a ‘copy and paste’. This is a popular request from clients on for two reasons: they perceive it to be more cost-effective and they believe it should take less time (which sometimes still has a financial motive).

Unfortunately, the idea of moving an old website into a new CMS is a bit like buying a Porsche and then towing it with your Pinto. It’s more damaging to the bottom line, slower than you’d expect, and completely relieves you of the joy of using what you bought. So let’s talk about what the issues are that arise from a “Lift and Shift” exercise.

 

What exactly is a Lift and Shift?

Here’s how Lift and Shift is often defined in terms of client requirements:

• Content on the existing website will be managed in a new CMS
• The website must look the exact same
• The client shouldn’t lose any flexibility in how content is managed
• HTML remains the same
• CSS remains the same
• JavaScript remains the same

The Project Management Issues

Lift ‘n Shift is why no one writes requirements

I’ve seen this way too many times. The project gets defined as Lift ‘n Shift , and therefore, no one has to document anything. Just copy and paste, right? That’s your one requirement, so what else do you need? You don’t go to a steak house and ask for beef, yet you’ve gone to developers and asked for a website.

I had one client whose project was a Lift and Shift for a tool that searched a customized medical library. We were supposed to ‘shift’ it from a customized application where articles were copied and pasted from a third-party… an online portal getting content from that vendor’s feed with a REST API. We were going from ColdFusion and MySQL to Websphere Portal 7.0 and some webservices. To the developer or architect, this is a huge deal. To the project manager who was labeling this as a Lift ‘n Shift, these facts didn’t even make it as bullet points on a PowerPoint.

You can miss explaining what you’re shifting to. 

So, the ‘no requirements needed’ policy in that scenario made it as far as the first time the developer had to ask me how to order the search results (I was the business analyst).  Then came the navigation questions: how do I create the hierarchy; what defines a ‘parent’ or child topic? And then we had the questions about URLs.  Since this was an application dynamically producing pages, we didn’t have SEO-friendly URLs like we did before. We had another application that linked to the articles, how do we do that without static URLs?

Once the developer started asking questions and realizing how in-depth the project was, he understandably changed his estimates. When the project managers got wind of the changed estimates, the business (me and my department) was accused of ‘scope-creep’ – at which point I had write 20 pages of requirements on the existing application – just so that I could prove that the scope had not ‘crept’ at all. Not only did we not save time and money by writing requirements in the middle, we lost money because the developer had to start over.

The scope can creep as much as it wants when you never establish it.

A lift and shift needs just as many requirements as any other project. Without full requirements, you have three ‘scopes’ of failure on your project:

1. Content Management functionality is completely missed . e.g:  a landing page produces articles statically instead of dynamically
2. Website functionality is reverse-engineered incorrectly.  e.g.:a developer not knowing business rules codes a form to behave as he sees it and it doesn’t change dynamically based on how the questions are answered
3. Website functionality is missing entirely. e.g.: The homepage carousel used to be responsive, and now it isn’t

The knee-jerk reaction in these scopes of failure is to fault the developer. What is unfortunate with this response is that the client has mistaken the quality of the developer with the quality of his requirements. At the end of the project, the developer or even the firm walks away with a tarnished reputation due to circumstances that were in the client’s control.

GIGO: Garbage In, Garbage Out. An application is only as good as the requirements. 

The deadline is wrong

It’s a natural result of not having requirements. The client and the project manager don’t see anything other than ‘copy and paste’ so there’s no reason this can’t take more than a week or two. Without requirements, the developers just have to explore and discover functionality, and nothing ruins a weekend like discovering functionality that we didn’t know existed. We sometimes call that, “getting Office-Spaced”.

In one project, we had a simple form that an end-user could use to find out which product was best under given conditions. I spent two days trying to understand how it worked, just so that I could make sure that the HTML we produced would be compliant with it. And then I discovered a 3,000 line JSON file that the JavaScript used… it listed every product about 17 different times, in 17 unique ways. Replicating this either impacts the deadline, or the developer’s sleeping hours.

We don’t shift fast enough

 The Content Management Issues

The lack of requirements gets us in trouble

We’ve touched on this already under project management, but it’s worth explaining in greater detail how it plays out in the CMS. Despite the fact that developers are a typically a smart bunch of guys, we’re stupid when it comes to the client. We don’t understand their business, their content, their organizational structure, or even their industry. So a requirement-free lift and shift gets us and the client in a lot of trouble:

• We think a page has more unique pieces of content than it really does;  now the content authors have to create 5 pieces of content for a single page that only get used once
• We think a page has fewer unique pieces of content than it really does; now the content authors have to create 1 piece of content that’s so big it takes half a day to create
• We don’t see the relationship between a box of links and navigation; the content author ends up creating duplicate content in the site
• We don’t make any user groups in the CMS; now the CEO and the janitor have both taken down the site*
• There’s no workflow or approval process created; you discover how bad your junior content producer’s spelling really is
• There’s a legal requirement that all content be archived or tagged with a unique number; now the site can’t launch until the changes are made

Even with requirements, we can’t turn one CMS into another

I’ve done both both types of  Lift and Shift: ‘bad’ CMS to ‘good’ CMS; no CMS to CMS. When I sat down with one client that was going from no content management at all,  the first thing I said was, “you will hate me and the CMS by the time this project is over.” Though they scoffed at the time, about a year later I was saying, “I told you so” as they were cursing my name.

When you don’t have a CMS, you have pretty much infinite control over the site. You can make one page as different as the next, your navigation can have any structure imaginable and you can put any functionality anywhere. When you go to a CMS, you can’t reach into the code anymore. CMS developers try to make everything programmatic; your navigation gets built by some set of rules and your pages all get the same stylesheet and JavaScript. All of a sudden, a special layout for a special page becomes a serious pain. Your navigation and sitemap are identical, and you can’t put the same page in three different places.

We shift flexibility away from you.

If there is an existing CMS, unless it’s an upgrade of the existing one, the client finds themselves baffled, angry, and confused when they can’t do things the same way. Images aren’t uploaded the same way, or you can’t find PDFs the way that seems natural. Or the way you make content isn’t as intuitive as it used to be. Now you can’t change a headline from one element to the other, or it’s harder to add custom images for your bulleted text.

We shift the wrong controls

It’s a work of art to create the perfect balance between the user of a CMS and the user of the website — no two CMS’ balance the scales the same way since they all have different strengths and weaknesses.

Sad but true, the limitations of a CMS often dictate how a website is architected.  A lift and shift  exercise turns one CMS’ weaknesses into another CMS’ misuse, abuse, and customizations.

A Lift and Shift often excuses both parties from setting new expectations about the CMS

The Code Issues

A lift and shift is, first and formost, supposed to be about the front-end code: don’t touch the HTML, CSS, or JS. Neither I, nor any of my colleagues, have ever accomplished such a feat. Not once have we ever successfully migrated into a new website without changing something in the front-end code. In fact, I’d say that you’ve got a leprechaun in your conference room if you got to keep 80% of the code.

Copying CMS-generated code

The CMS’ job is to take your content and wrap it in HTML. Then the CSS styles up your page and the JavaScript adds the cool functionality. Some CMS’ produce unnecessary HTML. They create spans and divs solely for their own purposes. Not only that, some CMS produce tables — those awful things front-end developers have been running away from for 10 years.  Some of the HTML on a site is there because either the CMS needed it, or the CMS made it. Leaving this markup in doesn’t make our lives easier; it’s more code for developers to misinterpret.

Copying your limitations

If a CMS can’t produce content with a certain look, one of two things happens: 1 ) The CMS produces a load of inline-styles that never made it into a centralized style sheet 2) The content becomes just a ‘code block’ where someone with HTML and CSS expertise is the only one that can edit it.

I’ve dealt with a case recently where pieces of content were created with a ridiculous amount of inline styles. Nearly every HTML element had its own background image, font size, and color. With a Lift and Shift exercise, I had no choice but to make this a solid piece of code managed in a CMS. The flexibility the client is hoping to achieve with transitioning to a CMS is completely lost because all I’ve done is Lift and Shift the need for a developer.

If we can’t improve the code, we can’t give you improved content management

When We Can’t Shift the Code

We sacrifice CMS flexibility because of the layout, or vice versa

It can kill the sensibilities of an HTML purist, but this indeed happens: the quest for semantic nirvana just doesn’t jive with a Content Management System. Sometimes we have to wrap content in an extra element of some sort. We have to figure out the pattern for when a page gets a sidebar, and then figure out how the CMS knows to put your content there. As CMS developers, we must generalize your code.

Being programmatic with your layout means that we need consistent rules for how it was created and how you put content in it. I had one client that used a ‘three column’ layout with a left sidebar. Their product detail pages appeared to be three-column, with highly specific product information in all three columns.

We ran into a problem, though, that in the far left column, right next to this highly specific and unique product  information there were two blocks of content that were generic and  reused all over the site.  This is a quandary where either this unrelated, reused content must now become part of my product content, or I must re-write all of the HTML and CSS.

When we can’t cut corners on the layout HTML, we cut corners with your content authors

We make the code more legible for us

Not all developers are created equal. At Tahzoo, our front-end developers are truly top notch and all follow best practices.  We use the same HTML5 boilerplate, we write modular CSS, use the same CSS reset, and we use the same JavaScript pattern for all of our implementations. We even have a standard of legibility that we keep with all of our front-end code. This means everything from how you format it (tabs vs spaces) to how you show nesting of elements and code is uniform (so that any of us can jump in on a Lift and Shift and deliver it by the deadline).

There’s a number of things we’ll do to make code legible in a Lift and Shift exercise, in addition to just formatting it:

• If the HTML or CSS  uses meaningless classes and IDs   f * {display:block} , We’ll change that to a class that’s meaningful, like franksDiv * {display:block}
• If there are too many html elements that lend nothing to the layout or the styles, we’re likely to delete them  just so that it’s easier to transfer markup: <div><div><div><div><h1>Headline</h1></div></div></div></div>
• JavaScript functions using variables that are meaningless var s = 1; might become var segment = 1 just so that we know what it does

We’ll rewrite the HTML and CSS when it’s not content manageable

A CMS developer has a unique challenge where we must not only replicate the patterns in your content, but create them where you meant to.  We’ll analyze the HTML, the CSS, and even the content and play a big game of ‘find the differences’. Even you though your left-side content and your right side content are wildly different, the HTML might be virtually identical. We’ll change your classes and IDs and sometimes save 6 hours of development doing so.

What should we do instead?

If we can agree that a Lift and Shift is a costly and poorly executed exercise, let’s talk about what we can do instead.

• Spend the money you’d spend on that Lift and Shift with a requirements gathering project (it’s what you’ll end up spending, anyway, on requirements discussions)
• Spend time on a content inventory or even a site cleanup; clean out the old content before you copy it over
• Spend money a project for improving the front-end code in the existing environment
• If you can’t improve the code on the existing site first, then pay for two front-end developers to prototype the entire site with new code; heck, just ask for an ‘HTML5 conversion’
• Ask an agency that specializes in CMS implementations for a review of your CMS, complete with an explanation of its limitations

All of these items cost the client money, and that hurts the bottom line. Yes, a Lift ‘n Shift is quick, cheap, and delivers something tangible in a short amount of time. And I’ve had clients openly acknowledge that their Lift and Shift was not the best idea, but the most affordable, as it assuaged upper management concerns.

“We’ll fix it in the mix”

Any musician who’s spent time in a recording studio knows to fear this phrase. “We’ll fix it in the mix” is what the producer says to the band when he doesn’t want to do another take to correct a mistake that the musician made. Rather than do it right, the producer will pull some tricks or hacks with how he mixes the the song to cover the goof. Fixing it in the mix is a guarantee that the song will sound horrible.

In the Lift and Shift scenario, the equivalent is,  “We’ll do that in Phase X.” When a developer raises any concerns over the quality of his code, or even the implementation, the client often settles this unrest with an undated, unbudgeted, and undocumented Phase [x]  — where all of these issues will get fixed. You can almost hear Homer Simpson saying, “That’s a problem for future me to figure out.”

Clients need to realize that their CMS is a bit like a tattoo; if it wasn’t done right the first time, the best hope is that it’ll be a hilarious story later because it’s too costly and too painful to correct it.  If I encounter a small issue that I feel can be easily corrected, I label it as a ‘bandaid’ in my code. A bandaid is for a temporary problem, and you should be able to pull it off without limbs falling off. In fact, a bandaid should be able to fall off when the problem gets fixed. The problem with a Lift and Shift is that a developer may be told to treat an amputation with a bandaid. Fast forward two years to find Frankenstein code and developers screaming, “kill it with fire!” in the break room.**

The Lift and Shift is never a good idea; at best you can hope that it’s a future awful idea.
*This is the only scenario which is not based in fact

**This scenario is not only based in fact, I’m not so uncertain there weren’t pitch forks involved