Reading Time: 7 minutes

Recently I was given a web project— but not just any type of web project. The kind we hate most. The one that’s best-labeled a “future awful idea”.  The one developers will try to kill —with fire. The kind of project with the same sad story as that Pokemon tattoo on your cousin’s lower back.  You know the kind of web project I’m talking about: a Lift and Shift.

A while back, Some handsome devil wrote a blog post on the problems of a Lift and Shift —and why clients shouldn’t ask for them.  So when a Lift and Shift snuck up on me, I put my own words to action and fought for a scope change with the best weapon I had: SDL Tridion. So I’d like to share how we used the best of Tridion to fight the worst of projects.

The Conjuring

First some bullet points on the original scope of the project:

• The client wants to put the website in Tridion
• The client will redesign the website…next year
• The client will change the information architecture…next year
• The client will have a new mobile strategy…next year
• Because the client will be doing a redesign later, they’re ok with throwaway code now

Preparation before Annihilation

Diplomacy first: Ask Questions

Our business analyst threw out the phrase “Lift and Shift” as one of the very first descriptors of the project. He’d read my previous post and knew my stance; a discussion on the problems wasn’t going to be productive.  Instead of focusing on the bad parts of the project,  we looked for good parts.

We talked about the current design, and what we knew about the new one. We discussed the timeline of that new design. We reviewed the content and the information architecture. We talked about the flaws that we saw in the user experience, and whether the client acknowledged those flaws. We even asked what gain, if any, the client got from a Lift and Shift. The client didn’t have any answers. They just wanted the site in Tridion before their redesign.  In all of our probing questions, the only benefit they saw was that there would be something in Tridion before the new design.

We tried to find the good in a project —before we called it bad. 

Know your enemy: Review the front-end

One of your basic Lift and Shift  rules is “as-is code”;  you need a clear definition of “as-is.”  In a Lift and Shift scenario, the HTML is the source of  business requirements. That HTML defines the header, the footer, and layout of the page. The wrappers for pieces of content are  schemas, and the content in those wrappers  are  schema fields. We don’t know how many page templates, component templates, schemas, or fields we need until we look under the hood.

We not only have to evaluate the HTML, but we look at the CSS and JavaScript, too. The CSS lends  clues as to which browsers are in scope (if the BA or client doesn’t know). The JavaScript libraries —especially jQuery and its plugins— tells us what interactive elements exist on the site.  When it comes to Lift and Shifts, we find more business rules in JavaScript files than in Word documents.

We  let the code, not the client, have final say in our project plan

Draft your battle plans: Draw your wireframes

When I do my front-end review, I click through probably 100-200 pages and I use a quad-ruled notebook to hand-draw wireframes. I first draw out very simple boxes with my own labels for the header, footer, and some pieces of content. Once I have a thorough grasp on the consistent and reliable parts of the website, I start over with Chrome’s Element Inspector opened up. In my second go-around I’m focused on the HTML.   I re-draw my wireframes and label the major wrappers of the page according to whatever class or id that I see. It’s important to find the distinction between what we see and what was coded.

Once I’ve drawn wireframes with labels that are the classes or ids of those wrappers, I dedicate a page or two to each major section. I’ll draw out that header and all of those interior wrappers. If the logo is wrapped in a div, I draw that div, too. I look at each container for navigation and I draw everything up to the individual <li>,  labeling my elements by the class or id that the CSS author has used to give that element shape.

Drawing your wireframes by hand sounds daunting and archaic, but there are solid arguments for doing so:

• In a Lift and Shift, your requirements come from the code, not the client
• By scrutinizing the visual, you also scrutinize the information architecture
• An HTML review lets you see a developer’s interpretation of information architecture
• Drawing out the HTML gives you a familiarity with your project
• Hand drawing the wireframe gives you time to mentally piece together the page
• You get to review the quality of code that you’re actually migrating
• Keeping everything in a notebook means you get a permanent reference to your project (future-you appreciates this)

We want to know the website’s strengths and weaknesses better than the client

Size-up your opponent: Grade the website

Knowing that code must change in a Lift and Shift, I’m not asking, “what has to change?”  My concern is, “How much has to change?”

Navigation that didn’t look global actually was. Major HTML wrappers didn’t consistently have interior wrappers. HTML was added and removed from the header on a per-page basis. Left-side rails were written completely differently than right-side rails — with multiple visually identical versions of each. HTML was styled on Ids, classes, both, or none. Not only did Ids and classes not follow a naming convention, they weren’t consistently cased:  .content, .Content, and #content all did different things.

Developers care more about accuracy while project managers care about precision; it’s a battle of paragraphs bullet points. The best way for us to explain the code was to simply grade it:

• HTML: 3/10
• CSS: 3/10
• JavaScript: 6/10

The client’s failing grade now is our failing grade later

Fighting the Lift and Shift: When Tools become Weapons

Before nunchucks were the weapon of choice for mutated adolescent turtles, they were used for flailing grain. It’s not so different when a project is scoped for failure; we fight scope with the tools in the cross-hairs.

Analyzing your Tools: Look at what Tridion does

SDL Tridion is an enterprise-quality  Content Management System. It’s a WCM or a CMS, depending on how you use it.  The operative term is content. Let’s discuss:

• People go to websites for the content
• Websites are built for showing content
• People will ignore old, unhip, uncool designs so long as they can find content
• Tridion manages content

We want the client to see that a Lift and Shift into Tridion is a bit like driving a tank into battle and shooting with a pistol (i.e. the best bad idea you’ve got).

Let the client see that Tridion is the right tool solving the wrong problem

Show off the Guns: Look at what Tridion does well

Once you’ve demonstrated that the scope of a Lift and Shift doesn’t align Tridion’s core strength, you want to talk about how strong Tridion really is:

• Tridion manages content in small blocks (components)
• Components are made with a schema
• Tridion manages the content separately from its presentation (a component template)
• Tridion lets you add, change, or remove presentations of a piece of content (multiple component templates)
• Tridion separates the content from the page ( A page can contain one or many components)
• Tridion manages the look of the page separately from the actual page (a page template)
• Tridion lets you add, change, or remove presentations of a page
• Tridion lets you change the information architecture of the website without changing the pages themeselves (structure groups vs. pages)

We had lots of ammo at this point in the project discussion. The information architecture was weak and inconsistent. A poor Information Architecture caused a poor front-end architecture. The only way the website could be shifted into Tridion was with literally copying and pasting the HTML; they would get a footer component and a code component — nothing else.

What we had from the client was a strong emphasis on putting things into Tridion for an eventual redesign. They were ok with throwaway code if they got to keep the content. What we had was a situation where they weren’t allowing us to give them any content to keep.

When someone asks for content, why give them code?

Victory through a common enemy: Put the content in your cross-hairs

If what the client wanted was reusable content, then why not give it to them? We presented an alternative solution, based on the fact that Tridion creates divisions of design, content, and information architecture.

• create schemas based off of existing content
• create components based off the schemas
• create pages with the components
• create structure groups with the pages

We explained to the client that it was ok that they couldn’t predict the future (i.e. the next look and feel of their website). Tridion doesn’t need content to come with code.

We also proposed creating blank component templates and a highly generic page template (that almost looked like the HTML5 boilerplate). With Template Building Blocks that don’t have HTML, you have no HTML to lose. Not only this, we gain the ability to retain the existing information architecture. This meant that when the new redesign comes, they get to change or throwaway content and add code.

And the client loved the idea

Summarizing the Battleplan

It was a careful and calculated effort to get the client away from a Lift and Shift. We first tried to justify the project, internally and with the client. When we couldn’t find any benefit to doing it, we sized up the situation. We acknowledged that the front-end code is the true source of business requirements —regardless of what  a client might say. In drawing wireframes based on the code, we gained valuable insights into how the website was put together. By acknowledging that code must change for a Lift and Shift, we recognized that the code was entirely too unstable to modify. Through our code analysis, we discovered that keeping the code in an “as-is” would turn Tridion from a content management system to a code repository.

We didn’t tell the client “no” along the way, and we didn’t  focus on the bad parts of the project scope. We highlighted the strengths of Tridion in comparison to the weaknesses of the stated project goals.  We didn’t let Tridion speak for itself; we spoke for it. We made it clear that Tridion doesn’t need code to house content, and that we can migrate substantial parts of a website without worrying about HTML, CSS, or JavaScript.  We helped a client see that’s better to let the content, not the code, write the requirements and future of a website.