To complete a tech migration, first change how you speak about it
© Shutterstock / Milan Ilic Photographer
Every few years, a company must rethink its platform, start to finish, which begins with the coding languages and its architecture. In this article, Rashi Khurana, Director of Engineering at Shutterstock explains how to (properly) complete a tech migration.
I joined Shutterstock in November 2015 because I was excited about the possibilities. I wanted to understand the business, both its customers and contributors and what had made it such a leader in its industry. As manager of both the eCommerce Images portion of our company and the Contributor experience, I envisioned building new tools and features to make the website and the site experience that much smoother.
Then, one day, I heard about a familiar issue we had to tackle: a tech migration. “Not again,” I said, thinking back on the two previous times I’d led similar work. Every few years, a company must rethink its platform, start to finish, which begins with the coding languages and its architecture. If you neglect this important work and grappling with the tech debt you’ve accumulated over time, then you will face even greater struggles down the line. The responsible thing is to face it head on, and that responsibility belongs to everyone.
It’s just difficult, I have found, to motivate people to get excited about that responsibility. After all, many of the people — including myself in this case — weren’t the ones who worked at the company in the years prior, who created the problem. How can you reasonably tell your team to put on hold their innovation in the name of getting the house in order? A project like that could take years to complete.
Coding language, like traditional languages, evolves over time. When we launched our site in 2003, Perl was the right language to choose. But we knew, to set up and thrive in the next generation for our organization, we had to make the move to NodeJs and React. Years later now, looking back on much of the amazing work we’ve finished, here are some pieces of wisdom I’d recommend to anyone about to embark on a similar project and fearful of how it’ll be received by their team.
Transformation, not migration
As our tech leadership gathered to discuss how to announce and prepare our teams for this assignment, we recognized that we should downplay the word “migration” throughout the process. This is a word with a negative connotation, and if you lean on it heavily, people will grow dismayed, perhaps even before the work truly begins. It’s a lot of heavy lifting you’ll be requiring of your developers, and you want to make sure they come in with the right attitudes.
Instead, we talked internally, in both small groups and more widely with the whole organization, about the transformation we were enduring and experiencing. Every engineer dreams of building new features and defining their work by innovation. We wanted to be able to honor requests we were getting from fellow employees and from customers about what enhancements they’d like to see on the site. But to enable that vision to come true, we had to take stock of, and grapple with, inefficiencies and obstacles that impeded progress within our infrastructure. It was not just the responsible thing to do, it was imperative to foster future growth.
As we embarked on migrating from the old infrastructure to a new one, we emphasized in our messaging the final product we were all growing closer to by the day. To achieve what we all wanted to deploy publicly, we had to first take care of the underlying, unseen work.
Celebrate good times
Moreover, as some teams broke free of the shackles of the old architecture, we asked them to present at tech demos and company updates, speaking of the promise of a new day. This motivated other teams to carry on and plow through, in hopes that soon they’ll join their peers on the other side of the terrain. We consciously injected into our work environment and company culture a feeling of camaraderie and hope.
For the teams doing the harder, heavier lifting, we knew this attitude shift would be a tougher sell. So for projects that required six or nine months to finalize, we broke them down and outlined them with detailed two-week sprints, to map it all out and show where the destination lived. Every week and every sprint brought us closer to the end. Even if you don’t stick to the exact timeline, having the destination in your sights can be a big pick-me-up during the more trying times.
When you look at how far along you are, it’s up to you to determine whether that’s significant progress or a sorry disappointment. Some people might say “We’re only 75.8% done…” but I’d encourage them to play up that they’re “75.8 percent done!” I recall one time when we accomplished a milestone, our team spent the afternoon celebrating with board games. After all, transformations are never really over, we keep iterating and growing.
Throughout this process, my team turned to me, not for solutions but to provide them with guidance and support. I wanted to instill, display, and project confidence. Here’s a brief rundown of how to achieve that standard — for yourself and for your team:
- Define a tracker.
- Take stock of all you do.
- Cluster the pages that exist on the old stack into features.
- Map the dependency for each feature.
- Get runway with features with no dependency, start those.
- Swag the projects.
- Get dependent team aligned to pick what you need next.
- Adjust, overcommit, and redefine your goals.
- Iterate, get out of your own way.
If you institute and stand firm with that plan, you’ll see greater impact and stronger results.
How to handle all that data
Data is one of the most complex problems to deal with during a transformation. Billions of rows of data need to be moved to a new home and exposed through APIs and services. To make this process a little less daunting, identify the new owners of each column in the database early on. Think about dual writing. If it a slow traffic part of the site, consider using a blackout window. If a portion of a feature has too much front-end and back-end work, phase the rollout by moving only the front end and continue to use remote procedure calls for the backend. Be strategic and weigh all of your options.
Lastly, post updates regularly and embrace transparency. Make it exciting for not only those involved but also the rest of the company; other employees should read about and hear about highlights and add to the cheer. A transformation impacts everyone. Since you can’t exactly shut down a 24/7 e-commerce site to do the repairs, it’s something that takes longer than you might wish it would. It’s a process that, if managed correctly, will bring on a brighter day.