By now I hope you are starting to understand there are some foundational items that are precursors to worrying about what your martech stack looks like. In my

first post

we discussed organizational alignment, then we discussed change management. Now let’s dig into the next topic that is down a level: adapting your business processes and tools.

Everyone has a legacy, and everyone thinks it will be critical to their future strategy. Prepare yourself for what I am about to say: it may not be. What is going to hinder or help you is the legacy technology and how your company is armed to move that into the future. In my previous articles, I outlined how organizational alignment and your ability to manage change will be keystones to your success in building and optimizing your technology. How you utilize, manage or sunset your legacy technology and data is the next brick in the foundation.

Once upon a company split…

To illustrate the importance of accounting for your legacy tools and technologies, I would like to share a recent client story. A long-term customer let us know they would be splitting off from their larger parent company. They were excited as they saw an opportunity to start from a clean technology slate. We thought it was very positive as well.

Their marketing automation system had numerous, very customized configurations that made its management difficult and error-prone. They had long ago reached the basic field limits because of unstructured, unscalable practices. In addition, the client had a complex technology environment in which they utilized multiple CRMs (of different vendors). They had several disparate business lines, each with different needs and requirements from a data model perspective. Their parent was a long-established company with very entrenched ideas and practices.

To move the company forward at the speed required to meet their timelines and objectives, the business owners for the technology made several executive decisions around how they would change processes (and consequently, technology configuration). These decisions were colored by the culture of the parent company and influenced by their knowledge of the past and future. They were very confident at that time.

Fast forward to the teams getting trained on the new technology. Suddenly, questions about the old platforms and old data resurfaced. While the decision-makers had accounted for many of the legacy systems and processes that the team had been using, it became clear that they weren’t aware of every facet.

How could this have been done better?

These unexpected questions had the potential to derail the client’s progress. How do they move them forward without losing momentum? They obviously should have looked at their legacy systems more thoroughly at the beginning. Remember, however, that one of the keys to managing change is being agile, not rigid. To embrace a more agile framework, the first step should be to understand the use cases for the legacy technology and data. Once those scenarios are understood, the project team can assess whether the systems and data will persist after the migration to the new technology.

When analyzing your own use cases, internal team members will often default to the “old way” of thinking and doing things. This is a natural by-product of hesitancy and resistance to change. 

Change management

is the undercurrent to nearly everything you do while optimizing, changing or creating your technology infrastructure.

For this client, the answer was relatively simple. Their legacy systems were to be mostly eliminated in a short timeframe, in six to nine months. Much of the data represented information that was not transitioning to the “new” company, so there was less of a need to migrate them onto the new marketing automation platform.  In most companies this is atypical, so how do you best manage systems and processes that have existed and need to persist?  Simply put, understand what the full slate of your systems consists of, then analyze whether the data held within them contribute to your larger business goals. Remember, first and foremost, each of the teams contributing to the technology changes you are undergoing

need a shared set of goals

.  Once you are working from a shared set of goals you can objectively decide what in your legacy technology is critical to the success of your shared business objectives.

What’s next?

Hopefully, the last few articles have given you an appreciation of the complexity you face as you optimize and work with your existing technology or introduce new ones. I have focused heavily on organizational behaviors and mindsets, factors that impact each of the five areas you need to address before you architect your martech stack. Next up on the list, I will explore how your business processes need to be managed prior to tackling your architecture.