Zendesk Web Content Migration
Project: Marketing Website Content Migration
In 2021, Zendesk was on a localization platform (TMS) that required a lot of manual work and limited the marketing team’s ability to scale. The Localization Director identified another TMS to migrate to, BureauWorks (BWX), and leadership allocated budget for an integration and migration. Adopting the new TMS would require my team to scrape strings and metadata from thousands of live pages and import them into our CMS.
I would manage two contractors to complete the project over 7 months. Our Director, my skip-level, set a hard deadline for the migration to wrap up in mid-September.
TL;dr—I delivered a successful integration and migration by the mid-September deadline without disruption to other marketing initiatives on the website.
My team’s two Engineering Managers and I began weekly meetings with Zendesk’s technical Localization Manager and a BureauWorks support manager and executive to define the specs and other high-level deliverables (such as process docs) for the integration.
I created documentation and processes for the two contractors to recode the templates for scraping, reserving additional prep work that required more complex domain knowledge and judgment for myself.
I built a REST API layer on our CMS that would authenticate app and developer users and enable content creation, update, and delivery via JSON.
I developed a custom multilingual multisite library tailored to our marketing team’s needs. I wrote a series of classes for multilingual site relationship management (two lightweight MySQL tables handled site and page relationships in the background) and multilingual templating tasks (such as image localization or generating hreflang tags for a page). I added robust unit testing for these classes and worked with our Test Automation Engineer to add the test suite to our PR quality workflow.
As our current localization platform provided mirror staging sites for new translations but BureauWorks did not, the scope of this work eventually broadened to include staging and cross-environment content transfer developer tools.
I developed an opinionated command line tool in Node called Teleporter that hooked into the new CMS API endpoints. Teleporter made it easy to push page data from a developer’s local copy of the site to their remote staging site, from our main CMS application to remote and local staging sites, and from those environments back to the main site.
Teleporter was easy to maintain, learn, and integrate into our high velocity workflows, successfully replacing the legacy vendor’s mirror site infrastructure.
As BureauWorks worked on a custom integration with the TMS and my CMS API (using documentation that I wrote), I worked with my Engineering Managers to plan the phased content migration, still targeting the original September launch date.
I had previously migrated some regional content from a different CMS into our blog using a scraper tool that I had developed in Ruby, Katamari. Katamari scraped Zendesk’s production site, parsed webpages for content and metadata, and exported the page data as either JSON or XML.
I extended Katamari to work with additional CMS post types (we had 7 total), using TDD to speed development. With good regression testing in place in Katamari from the start, I was able to delegate the addition of support for the last 2 post types to one of my contractors.
I installed a Node database migration library to enable programmatic, reversible changes to our CMS database across multiple environments. I developed a multi-step process for my contractors to migrate the bulk of the content with minimal supervision.
For existing pages (U.S. English), they exported JSON from Katamari and ran database migrations to update the pages in staging for QA. For net new pages (localized versions), the contractors exported the data as XML and used the CMS’s native Importer to import the XML. Once imports were approved on staging, I ran the approved migrations against the production database and the contractors handled the XML imports on prod.
Once we were in the middle phases of the content migration, the biggest blocker to progress was strings QA fatigue. This was mitigated somewhat with a QA tool that one of my contractors developed at my suggestion. His command line QA tool compared a production page with the imported version on staging and printed color-coded diffs in the terminal.
All of our launches went smoothly, and I launched the final set of migrated pages in September within a few days of the new TMS integration going live. My Director and the Localization team were very happy, and Loc was able to end of life the legacy TMS a few weeks later, well before the contract end date.
Having since worked on two additional migrations that others led, I know that delivering a migration smoothly and on time doesn’t just happen, and that missed deadlines and premature releases (with stakeholders blindsided by performance degradation or visible bugs) can be painful for the entire team.
A troubled migration can even create a perception of an underperforming team that should itself be replaced.
My ability to understand and design for systems end-to-end, anticipate and plan for complexity and risk, proactively intuit real user needs beyond stated requirements, and collaborate and delegate effectively ensured successful delivery of a high-stakes content migration five years ago when I was still a Senior Software Engineer.