Building a Product Owner – System Migrations

We have a problem with Product Owners in Agile.  These are incredibly difficult jobs and it is easy to blame the product owner when things go wrong because “the requirements were not clearly articulated or prioritized.”  That might be an easy path, but it often is neither correct nor fair.  Instead of pointing fingers, let’s support our Product Owner and give them the training and tools that they need to be successful.  Just like we introduced with developing New Products and explored with existing backlogs, here are some tips and tricks to managing system migrations.

Image Source:

Image Source:

Moving from old technology to new is a common project for Agile teams.  Many companies have platforms that are no longer providing the necessary value and features to the marketplace and IT organizations are faced with the challenge of moving from an old, tired, inflexible system to a new, dynamic, configurable system.  Or it might not be that dramatic – perhaps you just need to move from one software package to another for cost or vendor relationship reasons.  Either way, a new product owner must discover how to break this big effort down into manageable chunks.  How do you get started?

1. Analyze what is being used

The first step is to figure out what pieces of the legacy software are actually being used.  There is no sense migrating functions or features that no longer matter to the organization.  If you can weed out some portions of the migration to minimize the size of the effort, that is great news for the company.  Some firms want to skip this analysis step and just build “like for like.”  This approach will save time as part of the project prep, but it will cost precious developer time down the road.

 2. Map the Business Process

Sometimes, legacy systems have been around for so long that documentation is outdated and the company cannot remember exactly why we do things that way – “it’s just the way things have always been done.”  A new product owner can provide tremendous value to the organization by mapping the business process flows, preferably from the viewpoint of the customer or end user.  A process flow or Visio diagram can provide clear direction to the development teams when it comes to setting up the new system.

3. Prioritize the most important paths

Once the analytics are available for what features are actually used and the business process is documented, our new Product Owner has the data necessary to prioritize the most important paths to be delivered first.  Determining the priority can be based on the most often used functions or the actions that require the most manual intervention or introduce the most risk.  This prioritization breaks the project down into manageable, agile chunks.


Armed with this information, the Product Owner and Agile team can deliver the system migration with confidence.  New product owners need support and training.  Understanding how to tackle something as big as a system migration can set a product owner on a path to success.  And product owner success is necessary for Agile team success so everybody wins!


One Response to Building a Product Owner – System Migrations

  1. […] owner is on the road to success.  Stay tuned for future blogs on helping new product owners with a system migration or taking over an existing product with a healthy backlog.  We hope this series will help new […]

Leave a Reply to Building a Product Owner – New Product | Kristin Runyan Cancel reply

Your email address will not be published.