From chaos to order – How to succeed in a massive migration project?

Following the business acquisitions last year, we found ourselves in a pressing need to transition to a new Salesforce environment. Salesforce has been an incredibly critical system for us throughout our existence, around which we manage everything except invoicing. As you might have guessed, we were faced with a massive migration task that would involve extensive refactoring, architectural renewal, and development of new functionalities.

Despite our preparations, we still couldn’t have anticipated the massive and complex operation we were about to undertake. As the project manager, even I didn’t foresee how deep into the thick soup I would have to dip my ladle.

The migration wasn’t just a technical overhaul, although as a technical exercise it was massive. It was about having to act in both the supplier and client roles within the project. This change affected every single one of our employees, from sales to HR, meaning the migration had to consider everyone’s wishes and requirements.

Sales and marketing were wielding Salesforce like pros. The entire sales pipeline – from handling new leads to managing sales opportunities and executing projects – was meticulously modeled in the system. It also managed everything from customer relationship management, revenue forecasting, project management, time tracking, to human resources. In addition, the system integrated with the billing system and a few lighter marketing tools. The setup was nothing less than a powerhouse, humming with activity and slick efficiency.

When I said initially that we use Salesforce for everything except invoicing, I wasn’t exaggerating at all.

In the midst of chaos

The starting situation of the project was, frankly, chaotic. We were dealing with an environment that had been “hacked” from left and right over the past fifteen years. Consequently, this environment lacked unified documentation or clear ownership.

Our organization contained both technical and business knowledge, but, unfortunately, this information was scattered all over the place. Many experts who had developed our Salesforce environment over the years had already left the company by the time we started the project. So, there was a lot of work to do!

Building the team

As the project kicked off, everyone understood that the key to success lay in a dynamic and multi-skilled team, whose members would complement each other like pieces of a puzzle. It was clear that we couldn’t pin our hopes on just one person.

The team selection encompassed a comprehensive array of experts: it included business representatives from sales, delivery, and HR, along with technical specialists.

The technical team consisted of a project manager, an architect, developers, and a marketing consultant. Each team member brought their own perspective and essential expertise, which was crucial for the success of the project. From each function, the mentioned responsible persons were selected, and additionally, three to four key individuals were included to bring in more expertise and fresh perspectives.

As the project manager, I was responsible for ensuring that the new environment was ready for critical functions without any interruption in service. The solution architect also served as a hands-on configurator and was key to the technical solutions. One developer handled the migration of metadata and code refactoring, while another managed the data migration. Naturally, the marketing consultant took care of configuring MCAE and overseeing the lead pipeline.

To support the project, a handful of additional consultants were also called upon, bringing with them fresh perspectives and specialist expertise, which enriched the team’s comprehensive understanding and strategic vision.

Two-way approach: top down ja bottom up

At first, the project seemed like an impossible task because there was so much to do. Once we got over the initial shock, we started to outline the process together. We approached the project from two angles: top down and bottom up. In the top down approach, we focused on business-critical processes and functionalities. In the bottom up approach, on the other hand, we broke down the technology into pieces and went through the raw metadata.

The idea for our first Top-down workshop came from a well-known dating app, where a swipe to the right or left lets you select your preferred partners. We compiled almost all of the existing functionalities, underlying automations, objects, applications, and buttons into cards. We ended up with a massive pile of these cards.

Tagging all those functionalities was a massive groundwork indeed. After that, we asked the function reps to sweep the tags into different boxes labeled Yes, No, and Redo. “Yes” meant that the functionality was absolutely necessary and worked well as is. “No” indicated that the functionality wasn’t needed moving forward. “Redo” meant that the functionality was needed, but it required further development to be better.

The first round was a huge relief, as we were able to trim down a lot from our to-do list.

Next up was prioritization. After the first swipe round, the notes in the Yes and Redo boxes were prioritized. These notes were categorized under the headings One day, Nice to have, and Def must have at go-live based on their urgency. The result was exactly what we wanted: a prioritized backlog was created for us.

One object at a time

One key to the success of the project was the Skyvia tool, a data mapping and migration tool. With Skyvia, data mapping becomes a breeze, and unlike when using tools like Dataloader, every migration leaves a trace. Opting for this tool was undoubtedly the right choice for us.

Migration was practiced one object at a time by creating a new sandbox environment where data was migrated one object at a time. This way, a ready-to-automate chain of migratable data could be constructed.

The project’s biggest challenge turned out to be the architectural changes. We left all the “managed package” implementations in the dust, embracing fully customized solutions for every desired feature. Additionally, we tweaked some processes between sales and project delivery. The most labor-intensive new features revolved around simplifying time logging and enhancing the tool for planning personnel resources.

Only one shot

Right from the start of the project, it became clear that using the old and new systems simultaneously was not an option. There was only one chance to succeed. Therefore, the pressure to succeed was immense.

The migration itself ultimately took twelve hours. At that time, the old environment was locked from the users.

Data migration day was Friday, so there was a chance to tweak and check the data over the weekend. Everything went smoothly in the end. Come Monday morning, all ninety or so users logged into the new environment. Adjustments and the development of non-critical features continued over the following weeks, and by the last day of the month, invoices were sent out to customers as usual. The migration was a success!

An educational journey

The migration project provided several key lessons. First off, the top-down approach was highly effective. It was also beneficial to list all features, as it clarified the progression. Critically, involving representatives from various functions was essential. These representatives formed a diamond-tier team, playing a pivotal role in the success of the migration.

The project was certainly no cakewalk; it was quite stressful at times. During the migration, we had to be prepared to make tough decisions and manage the scope, especially since the timeline was already locked in.

Additionally, in the migration, the quality of data must be nearly perfect, so its verification cannot be overstated. Team communication was paramount, as everything was connected to everything else, and even a minor change in one functionality impacted the work of others.

In our communication, it was good to remind the team that we are truly starting with a clean slate now. It was time to boldly jump towards the new and not dwell on how things were usually done before.

The migration project was not just a technical overhaul; it was a journey that taught us a great deal about ourselves, our team, and how we work. It proved that even the greatest challenges can be overcome with a unified team and a robust plan.

For us, it was also an eye-opening experience about how things look from our clients’ perspective, and about everything our clients have to go through and endure during significant transformation projects.

Although we work extremely closely with our clients and support them throughout their transformation projects, we obviously can’t see everything. Nor do we always know the kind of pressure our clients’ key personnel are under. Now, with one more experience under our belt, we feel we understand our clients even better.

If you have a migration project or any other significant change initiative underway or in the planning stages, feel free to reach out!

Laura Pitkänen

Laura Pitkänen, who is passionate about tennis and has a lot of experience in project management, works at Biit in the dual role of consultant and team leader.