Merge Your Stacks

Conducting An Initial Technology Audit


For this first exercise we recommend structuring your marketing technology stack by product category with each layer assigned to a product category.  This will make it easy to align stacks side by side post-acquisition to see where redundancies exist. In a perfect world, the heads of marketing operations for each company would agree on a product category list to ensure that both companies are in sync right from the beginning.


As you embark on this initial audit, it’s important to identify every piece of technology that is being used to acquire, engage, retain, and support customers; not just the big platforms but all of the low-cost and free tools as well. It’s important to check in with sales, service and engineering, as sometimes these tools will live outside the boundaries of marketing. It’s also important to check-in with finance to make sure that credit cards haven’t been used for tools that no one is using, or that have been forgotten. As part of this process it is critical to identify any homegrown technology being used as part of the marketing technology stack, and in particular any code that has been written to integrate pieces of your stack. These internally developed products are frequently referred to as “dark tech,” because in many cases, very few people know that they exist and far fewer, if any, are tracking them. Finally, to ensure that you have a complete technology picture if you are using agencies to implement and manage technology for you, it is important to catalog those agencies and the products that are being implemented on your behalf. Make sure that you know who is paying for the product and understand the implications of severing your relationship with each agency, should that become necessary. Note: This also applies to 3rd party data providers.

This forensic exercise might be painful initially but getting this done ahead of the acquisition or merger closing will accelerate integration efforts later.

For this initial auditing exercise, we recommend collecting a basic set of information about each tool or piece of technology to give you a starting point when it comes time to consider rationalizing the layers of your stack.

Our recommendation:


  • Use case—What functionality does this product provide?

Contract Details

  • Contract owner (who at your company “owns” this contract)
  • Contract start date
  • Contract end date
  • Auto-renewal date if applicable


  • Annual and monthly spend
  • Spend variables (what causes spend to increase?)


  • Product owner
  • Product users
  • Version in use
  • Latest version
  • Integrations and method of integration 
  • Does this product meet data compliance requirements?


  • Performance measurement—How is performance measured?
  • Performance assessment—How well is this product performing? I recommend developing a scale or assessment process to create some uniformity in rating products across the stack.
  • Any concerns or issues with the product and how it performs 
  • Percent of functionality being used

Your cart