Reposted from the @CHIEF Blog on 8/13/2018
One of the best parts of working at CHIEF is the value placed on breaking traditional practice area silos—on a practical level this means we spend a lot of time collaborating, teaching and learning new skills. There is a omnipresent view that we should be continuously evolving, applying our unique backgrounds to new skills and adapting processes.
I just wrapped up a project where I got to learn how to use MySQL, an open-source, database management system, to analyze website databases and plan a complicated migration. I was lucky enough to get to work with a few CHIEF migration experts in the process, peppering Lynne with an occasional barrage of questions and working closely with Rian on the actual migration(s!).
When all was said and done, we streamlined the client’s backend architecture and merged multiple microsties into a new main website—and in the process learned a lot of really important lessons. At the same time, two other complicated migrations (one WordPress, one Drupal) also wrapped up, creating the perfect storm of lessons learned. Rather organically we realized the needed to update our migration process(es)—to make them both more efficient and run more smoothly.
Migration Requires Good Communication & Documentation
One of the biggest takeaways was how migrations really cross both the Digital Experience and Development teams. We have to do a better job of communicating, providing context and problem solving—together. Then we need to document it better.
"We're concerned with how content is surfaced, how it works and the way it connects to other pieces across the site"
As digital experience strategists, we’re concerned with how content is surfaced, how it works and the way it connects to other pieces across the site. We spend a lot of time strategizing, planning, and problem-solving. But in the handoff to development and migration, things were getting lost, and knowledge not transferred. As a team, we need to do a better job consulting with our site-building developers and migration developers to consider the best structures for content types and how they work together from the beginning. That means we all need to know the legacy content better-—the status, structure, and field types as well as how it should behave on the new site.
Having these conversations earlier isn’t enough—we also need to do a better job of working from a single point of documentation. So we created one (large) spreadsheet...
This allows us to record legacy content types, their fields, and the field types along with the fields that will be migrated (or not) to the new site. Additionally, the sheet links to wireframes and designs so when there are questions, it’s easy to access and track down answers. Gone are the days of trying to build new content types from wireframes or designs—guessing the field types, and then trying to shove round pegs of content into square holes of new content types.
Migration Best Practices Series
We didn’t just stop at trying to improve communication and documentation. We dove deep, we looked at all of our work critically and found ways to do our jobs better—and this is just the beginning. We are making changes to how we determine timeline and strategy, what tools we use to gather information, and what modules and plugins we use on sites. That’s right—this is gonna be a series, so stay tuned for part two!