1.2 Current state analysis
Start by measuring the current state of the world. Even if it goes against your instinct to dive in, measure first to know whether you are fixing the right things.

Introduction
Unless you’re launching a greenfield project with no existing architecture, you need a thorough understanding of the legacy product. Documenting that understanding is a precursor toward a future state. This may seem obvious as everyone goes through the motions of reviewing current state. In my experience, most take a haphazard approach, maybe using a template with a few high level topics to guide a fairly ad hoc conversation. Unless you work somewhere like Accenture (who has a process for everything), few approach discovery with a system. Discovery is rarely deep, or thorough.
In this activity we’ll approach discovery with intention: Planning out the activity carefully, getting the right stakeholders involved, and using a discussion format oriented toward the subject matter. The playbook includes a template covering 11 different areas of discovery each with specific prompts focusing on business functions, application volumetrics and architecture, infrastructure, security, operations and more. This planning pays off by delivering a more thorough understanding of the current state. A well-planned and very intentional approach now can make a huge difference later.
There are different paths forward when dealing with legacy systems, but most will fall into one of these categories:
“Lift and shift.” This colloquialism very accurately describes a move into the cloud or, at least, replatforming. It’s just what it sounds like: “Lifting” the legacy system out of its surroundings and installing (“shifting”) it into a new home.
“Modernization.” Often this is called rearchitecting. Instead of lifting the old and moving it somewhere new, there’s going to be some degree of change along the way. That change will modernize the legacy system, updating it to become more fit-for-purpose in its future state. Notably, though, it is still going to have a significant resemblance to the old system.
“Reimagining.” This is going back to the drawing board and taking up the creative process: Exploring new product opportunities, embracing changes in technology, and essentially inventing from whole cloth — but making sure the future state encompasses the business functions of the old system.
Each one of these relies on a deep understanding of the legacy system.
For “lift and shift” projects, it’s crucial to know all about the existing software, systems, infrastructure, and more. Without that deep understanding of the legacy architecture, moving it to the cloud would be hazardous in the least. In many cases, legacy systems pose delicate problems when moved to a new home: Some software is beyond its operational (and supported) lifespan. Knowing how to deal with this in advance is necessary.
“Modernization” implies a similar deep knowledge of the existing architecture — but in this case, so that we can strategically and surgically replace bits and pieces. Perhaps a monolithic on-prem database has outlived its useful life. We’ll need to develop detailed knowledge about the schema, inputs, outputs, performance requirements, interfaces, and more so that we can replace it with something more modern (and hopefully less expensive to operate).
Finally, “reimagining” needs us to build a deep understanding of what the legacy system does at a business level. Having intricate details of system architecture might be less important in this case — so long as we capture all of the business functions, capabilities, inputs, outputs and use cases it provides. Then we can imagine a new system, and hopefully a new user experience that is likewise “reimagined,” expanded, and modernized.
This chapter is about creating the detailed understanding you’ll need when moving forward with any project that builds on the past. Doing this now pays dividends later. You’ll expose hidden requirements, risks, limitations, or end-user desires that may otherwise be glossed over — but ultimately, will resurface. It’s better to know and plan accordingly from the start.
The playbook provides templates and recommended strategies for conducting discovery workshops. Except for the most rudimentary of systems, conducting this kind of current state analysis takes some degree of care in orchestration — you don’t want to waste anyone’s time. Making sure the discovery session creates value is important. We want the value to be visceral for our customer, exposing unknown information, eliminating risk, and accelerating the project forward.
Current state analysis depends on involvement from all stakeholders. Much of the “analysis” is actually interviewing other people. We need to ask for their time and attention. Hopefully this isn’t a surprise to the team: In 1.1 Team mobilization everyone involved will have gained clarity on their role and responsibilities.
With all that said, it’s time to perform a little software archeology. The first step is making sure we’re ready to begin our current state analysis:
If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!
Keep reading with a 7-day free trial
Subscribe to Customer Obsessed Engineering to keep reading this post and get 7 days of free access to the full post archives.