Setting a Deadline for Your Big CMS Migration
You’re planning to implement a new CMS. You have thousands of webpages craving an audit and rework. You know what system you’re going to use, but you have to build it out (and you still have to learn it). And you’ve been asked for a deadline.
Or maybe leadership has taken the liberty to give you a deadline and you need to figure out if their timeline is realistic or even possible.
How do you know?
You don’t, really...at least not yet.
There’s no easy way to predict end dates for large-scale migration projects. And, ultimately, you’re purely making a guess. It’s fine to start with a fuzzy timeframe (like a season/year) based on your experience with other web projects, but it’s wise to hold off on giving any firm commitments until you’ve had some time to complete a few key tasks and analyze your landscape.
Not only will you gain some objective info to back up and defend your deadline, but it will help your team succeed and actually enjoy the project.
Audit your site and break the work into sections.
My friend was leading content strategy for a client who wanted to migrate seven separate websites into one. At the kickoff, he was told expect to an audit of about 700 pages in total. But after the first site, he was already at 400 pages. Their 700-page assumption wasn’t going to be close.
We don’t often know exactly what to plan for until we know what we're working with.
Like many, I don’t eat the whole elephant at once. So I start my audits by breaking up the site (or sites) into more digestible sections. This gives me a big picture view of how much stuff I’m working with as well as possible phases or priorities for migration. Then, I like to audit each section pretty thoroughly to get at specifics.
There’s a ton of good info to glean from an audit. But when it comes to predicting a timeframe for migration, an audit helps me understand:
How much content work is needed in each section (rewriting, reorganizing, new writing, etc..)
What functionality we’ll need to build in our CMS
Assess your content needs and flow.
When performing the audit, I make sure to get a good sense for how much writing and rework is needed, section by section. Understanding specific content needs often depends on lots of factors. Are we moving to a new design and template? Does that design require different content structures and components? How closely does current content align? What’s missing? When was the content last refreshed?
I also assess our content workflows so I can spot potential roadblocks and slow downs. Where is source info coming from? How many rounds of review will we need? How many people will need to see it? Which departments provide quick turnarounds? Will it sit with legal for a few weeks? If I can, I overestimate the time I'll need here. People processes often flow more slowly than we predict.
After making an initial guess at writing time and noting which sections might get hung up, I can better estimate how long each section should take (days, weeks, months) and get a feel for the overall editorial scope.
Determine and prioritize your development requirements.
Another core goal of my migration audit is assessing CMS build out requirements for all content that will move over. Within the audit, I create specific columns for:
Content template, structure, or type(s)
Existing functionally to rebuild
New functionality (based on new content we’ve planned or what I know about updates we’re making)
These columns allow me to take inventory of all structures and functionality we need working in the CMS before we can migrate each section. From here, I create a master list of templates and widgets and sit down with the development team to start planning how much time is needed.
You don't necessarily need to get after exact time estimates for each requirement. Instead, it's more about identifying what elements will take the most time to get an overall sense for build out. And always allocate extra time for what you don’t know about yet. Something will pop up.
As you go, it can be helpful to put requirements in a priority order:
Shared/most-used templates and widgets
Unique widgets - required for basic usability
Unique widgets - nice to have
You’ll likely need to launch before each little widget is finished. So a priority order helps you set expectations for where you’ll trim the fat and cut hours to make your deadline.
Learn your new system.
If you’re working with a system you already know, this should be easy. But if you’re implementing a CMS that’s new for your team, you’ll need to learn enough about how it works so you can estimate how long tasks will take.
CMS processes can be clunky and odd. You don’t know where the buggy quirks are until you spend time actually trying to build out some stuff to see how it works.
If you can, do a trial run. Look at your audits, pick a small section that makes sense, and start tracking your time. How much is ready to go out of the box? How much development work is needed? How much of your work scales to other sections of the site? Does it get more efficient as you go? How well does the migration tool work? Does it take 15 minutes or 15 hours to migrate 100 webpages? How much clean up work is needed?
You don’t need to have exact figures. Just a general understanding of how things work:
Build a content template or widget
Create a workflow
Run the migration tool
Clean up a set of migrated pages
Build a basic webpage
Look at the API
Etc.
Also, assess the overall complexity of your CMS and how you'll distribute tasks across your team. What skills are required for building new pages? Who can create new workflows? Who can access code? How easy is it for non-developers to build new content structures? If you have limited developer cycles and a highly complex CMS, you might need to extend your timeline.
Identify what needs to happen outside your team.
Who manages your server environments? Do you have to integrate with a CRM or identity management system? Are these systems supported and maintained by other teams? Do you need a bunch of data retagged and cleaned up in someone's ERP before you can pull it into the new CMS?
For most large web projects, I’ve had to partner with groups outside my core web team to complete most integration tasks. It’s hard enough to prioritize and set deadlines for one team, but it’s even more challenging to coordinate the work of other teams who have competing projects and different leaders.
If you can, it's good to start these conversations right away. A lot of problem solving is often involved, so this gives people time to strategize together, identify challenges, and find solutions to potential roadblocks.
Set up meetings and hash out schedules to figure out how long it will take and when the work can get done on their end. Good communication ensures you set an overall deadline everyone is comfortable with and helps you set smaller milestones within the project.
Analyze your organizational context.
Each organization has a certain modus operandi. We do things a particular way and set expectations for our work based on how things generally roll.
When predicting deadlines, I try to figure out where "our way of doing things" might cause some hiccups.
Do we have a lot of strict processes we need to follow? Does everyone get involved in everything? If so, allocate extra time for review.
Is there a busy season and a light season? If so, you don’t necessarily want to launch something when the website is getting the most traffic or when you won’t have enough folks on hand to help.
What other major projects is the institution juggling? Could they impact your resources? Call these projects out with your leadership and ask them to identify priority early in case you have to make a hard call midstream.
Does leadership expect firm deadlines? If so, pad yours with extra time. Finishing early is always better than running behind or being forced to launch something that’s incomplete.
Look over your assessments and make an informed guess.
There’s no clear formula for working your way through these tasks to help you assess an appropriate timeframe. Maybe after analyzing your organizational context, there’s an obvious window you have to meet. Maybe you’re able to calculate a precise migration timeline using your audit.
More likely, your findings will be a bit messy and nuanced. But that’s okay. Don’t commit until you know your stuff and don’t let others bully you into setting a bogus deadline before you know what you’re working with. Take time to gather enough info early so you can check your gut and set your team up for success by making make the best guess possible.