Real-World SaaS Migration Advice

By Jim Cloughley, VP Software Engineering, Microdea

A VP of engineering shares what he learned from his company’s transition to the cloud (hint: it’s as much about people as it is about technology).

So, you’re migrating to SaaS. A significant amount has already been written on how migrating to SaaS can introduce risk to a software company.

The majority of the reading I’ve done on this topic has discussed the business model, go-to-market strategies, pricing, sales structure, compensation, and last but not least, finance considerations. However, as the leader of a software team, the challenges I faced were all related to the operational excellence required to be successful delivering a SaaS product to market. Here are some lessons I’ve learned as Microdea went through our migration to SaaS.

WHERE TO START
The goal for me was to be able to deliver incremental business value through software releases several times a day. My engineering team was made up of qualified professionals with many years of experience in software development. Yet, the majority of the team was accustomed to long dev cycles that are typical with on-premises software.

I started the process by sharing a basic vision with the team through a series of discussions. Then we went through a series of “what must be true” thought exercises. For example, we asked, “What must be true if we want a developer check-in to version control to push into a production environment?”

This implied we needed a few things:

• The way we developed software had to change.
• Quick feedback from QA.
• Gates to halt promotions to production if errors were found.
• A way to undo a release if it were pushed to production.

But that was just the start. We realized we needed to develop new skills. We implemented Scrum for a small team and worked to make that team successful. Once we got it right, we expanded to a larger team and more projects. This process takes a significant amount of time. How long do you have to repeat something before it becomes a habit? The answer is “it depends.”

Even a team that has bought into the process will still make mistakes and has to learn from those mistakes and then adapt. All teams are different so it’s hard to pinpoint how long it will take. I’m suggesting that you should plan for this to take longer than you think it should take. How much time it takes for a team to transition will depend on how well you support the transition. That will be different based on the circumstances and skills of the leaders and the teams. I’m not going to say that this should take two months or five months. Focusing on the day to day will lead to a successful transition. Even now, after we’ve made the switch, the team still can improve. You’re never really done.

TECHNICAL ADVICE: TRACKING & TESTING
Every day, every week, you should be relentless on tracking, measuring, and comparing current progress to past progress. Work to understand why some sprints go well while others don’t. Be up front with the team and discuss challenges openly without consequences. Address roadblocks that the team brings to you. Solve problems as a team.

In parallel, we created a dedicated DevOps role that focused on “beyond the build.” We worked to create a continuous integration/continuous deployment (CI/ CD) pipeline. This took time to select a tool that was appropriate for our dev environment, and it took a long time to get it right.

Next, we wired in our automated tests so before a build could be promoted to QA, all of the automated tests had to pass. QA would pick up any build that made it through, and, if the build was good, it was promoted again to a staging area. In staging, we did load and performance testing.

We also introduced feature flags. A feature flag encapsulates new functionality so it can be turned on or off using configuration. Features are initially released disabled. Then we turn on a feature for a subset of our users in order to get feedback and test for stability. If testing is successful, the feature is propagated throughout our customers.

PEOPLE ADVICE: THE IMPORTANCE OF HIRING & ONBOARDING
During our SaaS migration, we also happened to have a huge growth spurt, which meant we were hiring very rapidly. Hiring the wrong person (or people) could have had a large negative impact so we changed our hiring practices. We introduced a quick phone screen that evaluated two areas. First, we asked the same set of technical questions to each candidate so we had consistency and could assess where they were from an experience level. We actually looked for people to say, “I don’t know.” It was better for candidates to be honest and explain it was an area they weren’t familiar with than for them to make up some answer. Second, we asked for examples from their previous jobs where they had faced adversity and asked how they overcame obstacles. We asked if they set goals for themselves, like learning a new technology. We asked for examples where they had helped others on their team when there was nothing in it for them. Overall, we assessed candidates for maturity and discipline by looking for evidence of a person who was well-balanced, curious about technology, and a great team player. The phone screen quickly disqualified people that likely wouldn’t fit our culture.

Once hired, we focused on making the employee onboarding process better. We introduced a survey that asked new hires what would have made their onboarding better. Then we followed through and made changes to address any hiccups they encountered. Sometimes, we’d forget to buy a license so we created and followed a checklist by role that listed exactly what each new hire needed. This list included hardware requirements for their laptop, all the software licenses they’d need from day one, business cards, etc. We wanted to make sure they had everything they would need to feel welcome and get up to speed with fewer issues. In addition, we also did all of the regular onboarding around software check-ins, practice and process around, pair programming, testing, and code reviews. We instilled accountability for software quality.

Most of all, the team iterated. We didn’t initially appreciate that everyone has their own learning curve, and it will be steeper for some. It is essential to practice week after week, with appropriate support where necessary. Expect to make changes constantly until the team is working well. When you think the team is really working well, find a higher level of excellence to achieve.

JIM CLOUGHLEY is the VP of software engineering at Toronto-based Microdea. He has worked in the enterprise software space for 20+ years and has held progressive technical roles focused on code, teams, practice, and process. At Microdea, Cloughley is responsible for leading a team including developers, quality assurance, technical writing, and support.