Migrating thousands of pages to a new CMS

Learning the system

For the first month of the project, we pored over every document and video we could get our hands on about the new CMS. Our vendor led us through training sessions, and then we set up test environments to explore its capabilities.

Once we understood the tools, we got to work planning our milestones and digging through the content to figure out how we needed to build the system.

Setting the strategy 

I spent a lot of my time for Bethel knee-deep in spreadsheets, mapping out how we’d move thousands of pages of content.

Thorough audits of Bethel’s website gave us a solid understanding of what the new system would need to do. We then used those audits as a roadmap to take us from planning to build out to launch.

During this stage, we also consulted with our SEO vendor to plan major changes to our information architecture before we started moving content.

Building a CMS from content models

After auditing a section, I'd plan any content models that were needed by answering questions like:  

• Where will structured content be most effective?
• How structured can we get? 
• Where should the content live?
• Where does the content need to go? 
• What pieces of content are related? How will they talk to each other?
• How will authors interact with the content?

Defining the content structure

As I moved through each section, I worked with designers and developers to plan what functionality we needed to build.

Creating the structure in the CMS

 Then, I’d ensure the new tools and templates in the CMS fit the content needs and worked properly before migration.

Planning for responsive

On the back end, our developers and designers built our templates so they'd be flexible for a new responsive design we planned to roll out about one year into the migration project. This meant all of our content needed to be responsive-ready. As we went, we built our structures to match mobile content priorities and adjusted existing or created new content as needed.

Migrating and proofing

We used a tool from our CMS vendor to migrate a lot of the existing content we knew we wanted to keep. If we were making major changes to the structure or producing new content for the section, we'd load the content manually as part of the proofing and review process.

After migration, we'd comb through each page to make sure headings, meta descriptions, links, and files were formatted correctly and fix anything that didn’t transfer cleanly. I also created tracking systems to distribute this work across the team.

Then, we’d publish out the section to a staging server and proof on multiple browsers and devices before launching to the public.

Creating workflows and planning for maintenance

Finally, we needed to create workflows and permissions to help our authors access and publish their content. I worked with the team to:

• Set access levels
• Create roles, groups, and permissions
• Build and test workflows to make sure each piece of content moved through the proper checkpoints

As we launched each section, authors went through training and gained access to their content.

Providing easy access to high-touch content

We also built tools for community members to contribute and edit content without needing to log into the CMS and navigate to their pages. We did this for high-touch info that needed to be maintained by lots of different people. For example, we built a form allowing faculty to update and expand their bio pages. All information they submitted or edited was sent back to and published out through the CMS.

Managing redirects

Another helpful maintenance tool we built allowed web team members to easily create, remove, and monitor redirects. We also integrated this tool with our deletion workflows to generate redirects automatically when pages were removed from the system.

Communicating and collaborating

Throughout the project, there were lots of moving pieces touched by many different people. To keep folks in the loop we used a few different technologies.

• Github - for tracking issues/bugs, requesting new enhancements, testing fixes, and communicating code updates
• Slack - for real-time conversation and problem solving
• Footprints - for working with writers and internal clients to produce new copy
• Google spreadsheets - for auditing content, tracking migration status, and conducting browser and device testing

To ensure we had plenty of face time, we met every Monday and Thursday as a team. And we scheduled build-out days where we'd book a room off the main campus and hammer through major sections, enhancements, or challenges together.