I have a love/hate relationship with site replatforming projects: Migrating from one CMS/e-commerce platform/whatever to another is an opportunity.
Great things can happen! Yay! You can launch a faster, easier-to-use site that’s also easier to maintain and better supports your business.
Or, you can end up with a feculent pile of badly-written code and shortcuts that bogs down your business until the next time you replatform.
You want great things, not feculent piles. This is my stream-of-consciousness list of stuff you must do for a stench-free project:
Ask The Hard Questions
Replatforming sucks. Do you need to do this?
- Is your website making money right now? If so, read the next few questions carefully.
- Did you just hire a new head of marketing? A new development company? Are they the ones pushing for the replatforming? Then pause. The new folks have the best of intentions, and they may be right. But they don’t have the context.
- How much money does your site make right now? How efficiently does it make that money? If over the next two years you increased efficiency 10% or increased revenue 15%, would that cover the cost of the replatforming, therapy, and antianxiety medication? The 10/15 combo is my experience, and if it’s not enough, think about next steps.
- How much will this really cost? For every dollar you spend on software, development, and design, you’ll spend a dollar on meetings, collecting data, cleaning up spreadsheets, and scrubbing special characters from outdated content.
- Can you make phased changes? Fix three annoying things about the design. Change platforms without redesigning. If you did it a step at a time, would you make enough progress to keep yourself and your customers happy? If so, do that instead.
- Is new technology forcing you to completely replatform? If a new CMS or e-commerce tool forces you to change your site design, fulfillment process, or workflow, it sucks. If those things all suck and you want to change them, OK.
- Is there any way, at all, that you can spread this project out? Seriously, have you read 1–6? Replatforming isn’t Winterfest. It’s boot camp. Avoid at all costs.
You’re still here? OK, continue:
Build The Team
Developers are great at building stuff. SEOs are great at SEO’ing stuff. Designers are great at designing stuff.
You get the idea.
What none of them are good at is miraculously taking charge and seeing a replatforming project through to completion. Don’t expect that. It’s not fair. Instead:
- Find that One Person. I’m bragging here, but you want someone like me: They’ve been involved with a lot of these projects. They’ve done a bit of everything. Most importantly, they are a cantankerous, highly-cynical old/young fart who wants this to go well, dammit. This person will keep everyone grounded during the honeymoon and sane when the excrement hits the turbine. Since I bragged, don’t hire me. Find someone else. But find them.
- Find a project manager. I don’t know how good project managers do what they do. But a good one will save the project and your sanity on a weekly basis. Invest.
- Hire a developer, hire a designer, and hire a content team. For God’s sake. What do you think a website platform delivers? Good feelings? No. It delivers information that gets folks to vote/buy/request/read/whatever. Someone needs to make sure that information is good. Whether it’s one person or ten, this team will rewrite, plan, and put the polish on your brand.
- Do not believe a development agency who says they know SEO or an SEO agency who says they know design or a designer who says they’ve done Salesforce Commerce Cloud implementations. All of these folks have the best of intentions. They don’t have the depth of knowledge to understand what they don’t know.
- If you hire a full-service agency, excellent. You still need #1.
- Check references. You need to talk to someone who hired this team/specialist to do something very similar for their site. If the reference says it went flawlessly, they’re lying. Find out the folks you’re hiring handled adversity. Find out what went wrong.
- Which brings me to the next hint: Don’t look for a perfect record. If someone has flawless references, they either killed everyone with a complaint, or they’ve never handled a replatforming. Remember, replatforming sucks.
- It’s OK to take a risk on a new team. Just go into it with open eyes and have that One Person.
- Remember that a team of five is better than a team of fifteen. Big teams don’t make good stuff. They make more stuff. Hint: Ask your project manager about team size.
- If you’re the boss, do not meddle. The moment you touch design, development, content, or anything else, it will turn to utter shit.
- Do set clear expectations. A colleague and mentor taught me this. If you want the fastest, most usable site out there, tell your team. If you favor design over all else, tell them that. Determine who’s accountable for what. Make it crystal. Clear. Then own the outcome.
- Regarding expectations: Set the deadline and get commitment to a budget. Make sure every team is on board until this is done. But just in case, make sure your contract includes knowledge transfer and your ownership of assets.
- Plan a transition at the end of the project. Who’s going to manage the site? Handle site changes? Troubleshoot?
- Plan serious documentation and training. Knowledge is power (cue Schoolhouse Rock).
Do The Work
This could’ve been a whole separate blog post. It is not a site best practices list. These are all the little details that might bite you on the arse during replatforming:
- If your business doesn’t need an exotic solution, don’t build one. You are not here to be someone’s case study. Use tried-and-true solutions.
- Don’t code into a corner. You can’t launch with every desired feature. You’d end up with Microsoft Windows (sorry, small dig). You must make sure you won’t be building another site a year from now.
- Make sure you have three copies of your site: Production (live), QA (where you test stuff), and Dev (where you build stuff). QA and Production should be virtually identical, serving the same content. Dev can be whatever the heck you want. This doesn’t have to be fancy. For ianlurie.com, Dev runs on my laptop. Another copy on my laptop is QA. What you’re looking at now is Production. This is a teeny 50-page site, and I still break stuff. Imagine what can happen with a 10,000-page B2B site.
- Content entry should allow formatting without resorting to workarounds. Lists, character formatting, special characters if you use them, and image embedding should be easy for a non-nerd.
- If you do things like special promotions, product bundles, and demos, make sure your new site supports them.
- If you don’t do things like special promotions, product bundles, and demos, don’t drive your team nuts building them. Just make sure you can build them later.
- If you can, preserve your original URL structure. It will save you a world of pain. URL permanence is your friend.
- If you must change your URL structure, find the top 20% most-visited pages on your site. Add them to a spreadsheet.
- Then find the top 20% most-linked pages on your site. Add them to the same spreadsheet.
- Find the top 20% most-engaging pages on your site: Most shares, lowest bounce rate + highest time on page + whatever. Add ’em.
- Find the top 20% most-landed-on pages on your site. These are the pages that get the most traffic from organic search, other sites, or other channels. Add ’em.
- Export every URL from every ad campaign you’ve run on any channel in the last year. Add those, too.
- Finally, find the top 20% highest-converting pages on your site: Highest revenue, most leads, whatever. Add those, too.
- Take every URL in that sheet. Find the new URL for those pages (because you’re going to keep those pages). Note the new URL. That is now your redirect list. Every old URL will 301 redirect to its corresponding new URL the day your site launches. That day.
- Resize and compress every product image, every image in content, on your entire site, before launch.
- Don’t expect your developers and designers to build your site without content. Give them everything.
- If the new site has new content, rewrite it before the project even starts HAHAHAHAHAHAHAHAAHA I’m kidding. Provide the team with sample content for each page type. “Real” sample content, not re ipsa poopoo. Show them what you’re going to provide. Will every page have a hero shot? Header content? Subheads? Make sure the team knows that well in advance.
- Go through your entire content database. Product copy, blog posts, solutions pages, and everything else need to be scrubbed. Remove all that inline CSS, MSO-NORMAL, inline script, etc. that’s crept into your content over the years. Before you do it by hand, talk to your cantankerous old far, your content, and your dev teams. They may have automated solutions.
- Verify that whatever caching/CDN you’re using allows you to update site content at the desired pace. For example: If you update your product information pages every day, make sure those pages refresh every day. If you update every hour, your cache should refresh every hour.
- No content workarounds! You may remember to add a hard return after every image or to add “?foo” after every link, but your next five hires won’t, and you’ll go out of your gourd reminding them.
- No fulfillment workarounds! Your third-party fulfillment partner will not filter out all the special characters your shiny new e-commerce system inserts into the Qty field.
- No lead handling workarounds! Your sales team will come upstairs and punch you in the face the first time they accidentally call Fiji because they forgot that the new system adds three zeroes and two ones to every number.
- Set your defaults. Description meta tags, image ALT attributes, image placeholders, and anything else that might end up blank should instead use other page content. The description tags use the first two sentences on the page. Image ALT attributes use page/product titles. Consider every piece of content on your page, and figure out what might replace it. Just in case.
- Don’t use drag-and-drop tools to build sites with complex workflows. It never works.
- Test your analytics in QA, not production.
- I’d say “never make changes in production,” except during the weeks after a relaunch, we all make changes in production. Just be sure to replicate them in QA and development right away.
- Be ready to delay. Don’t get into the dammit-we’re-going-to-launch-now-no-matter-what mindset. Your customers don’t give a flying crap if you launch two days or two months late. They will never forget a busted site.
- At the same time, don’t let the project go on forever. If you’ve doubled development time, sit down with the team, and find out what’s blocking.
- It is someone’s fault. If something doesn’t work, or if someone’s blocking, yeah, it’s a problem. Someone probably did something wrong. It happens. Don’t have a tantrum. Figure it out, own it, and get the work done.
- Finally: Assume launch day will be launch week and plan for chaos. Slow down the content calendar. Warn the sales team leads may drop. Get the fulfillment team prepped for weird spikes and drops in orders.
What Are The Stakes?
My last advice: Keep a little perspective. If (when) you get frustrated, pause, step back, and consider what’s at stake. Don’t let the broken images send you into an emotional spiral. Plan one step at a time, launch one step at a time, solve problems one at a time. Replatforming is hard. A nightmare, even. But you can manage it for a great outcome.
I’ve been working on this post for a couple of years. I had a fancy one, got sick of revising it over and over, and finally turned it into this list. All of this means that if you read this and say “Hey, Ian’s talking about me!” I’m not. Rest easy. Love ya, but I can’t even remember my passwords, never mind every project I’ve worked on.
Hate what you see? Love it? Tweet me at @ianlurie