6 Key Factors in Successful System Migration and Upgrade Stories

One project that stands out involved moving a core internal platform that had been used for many years into a modern environment built to support higher reliability and clearer security controls. The older system held many informal habits that were never written down. People relied on those habits to complete daily tasks, so any disruption would have affected several teams at once. The goal was to deliver a migration that felt steady and predictable rather than abrupt. The first important step was observing how people used the older system during normal work. Written guides did not reflect the small actions that staff performed every day. These observations revealed patterns that shaped the design of the new setup. Preserving the parts that people depended on helped prevent confusion and reduced the learning curve.

Clear communication kept the project stable. Regular updates helped staff understand what would change and how the transition would unfold. A pilot group tested the new system early and shared direct feedback. Their insight removed many issues before the full rollout. This made the larger transition calm and prevented last-minute surprises. Training focused on the tasks that mattered most to daily work. Sessions were brief and centered on practical steps. Support teams stayed close during the early days of the rollout so no one felt isolated during the change. This steady presence helped people gain confidence in the new platform.

The migration succeeded because the project respected real work habits, maintained clear communication, relied on early testing, and provided consistent support during the transition. These elements created a path that felt natural for the staff and allowed the organization to move into a more stable and secure environment without disruption.

One of my most impactful migrations involved consolidating our multi-app architecture. We had two mobile apps sharing a substantial amount of code through a separate core repository.

Initially, we maintained three repos: two app repos and one core package repo. This setup worked well early on. We reduced duplication and maintained consistency by sharing the exact same code. However, as the core grew, updating it became increasingly painful.

The problem was dependency management. Every package version in core was pinned, and many packages depended on each other. A simple update involved updating multiple interdependent packages within core (several commits), synchronizing those dependencies across both app repos, and resolving version conflicts between apps. This process routinely consumed 1-2 hours per update, which significantly slowed our development speed.

I initially considered writing a custom script to download and place the core repo alongside each app. However, while researching solutions, I discovered git submodules, which turned out to be designed for exactly this use case.

I migrated both apps to use the core repo as a submodule. The impact was massive: developers could see all code in one place, and updates required a single command instead of hours of digging through dependencies. And the most important part of it all, developers’ experience improved drastically.

The key factor that made this migration successful was that every developer had experienced the problem firsthand. We knew exactly what we wanted to achieve. On top of that, taking time to research led to discovering the native git solution rather than building custom tooling.

One project that stands out in my career was leading a full migration of a complex product to a completely new design system and brand identity. It wasn’t just about changing how things looked but about rethinking navigation, restructuring workflows, and modernizing components that had become inconsistent over time.

What made it work was a systematic approach: I kicked off with a thorough audit of every user flow, collaborated closely with engineers to understand technical constraints, and rolled out the new system in carefully planned phases. On top of that, we trained the teams on using the new patterns to ensure design consistency after launch.

The result? A cleaner, more cohesive user experience and a solid, maintainable design foundation that sets the stage for smoother development going forward.

This story reflects an approach many successful migrations take: deep collaboration, clear planning, and ongoing education to keep things consistent beyond the initial launch.

One of the most impactful migrations I led was a transition from QuickBooks to NetSuite for a company that had outgrown basic accounting but didn’t yet have the internal controls or reporting maturity to scale. Before we touched a single line of data, we rebuilt the chart of accounts by standardizing naming conventions and by cleaning years of inconsistent entries so the system wouldn’t inherit legacy issues. We then documented every upstream and downstream process, including order-to-cash, procure-to-pay, inventory movements, and approvals, so that workflows would be clear. Finance partnered closely with operations and IT to design custom roles, permission sets, and approval routing so finance gained stronger controls without slowing down the business. We ran parallel testing for two full cycles, validating not only balances but also how transactions flowed, where bottlenecks appeared, and how reporting tied out. By go-live, nothing was left to guesswork, and what made the project a success was the clarity, discipline, and cross-functional alignment built along the way.