If you’ve decided to implement new software (or are thinking about it), keep reading. This could give you a completely different perspective from what you’d expect.
Naturally, most of the attention usually goes to the software itself. Which platform should we use? What features do we need? How should we configure it? What can we automate?
Those questions matter, but there’s another question that often becomes much more important once the implementation actually begins: What data is the software going to run on?
A new system can have exactly the features your business needs and still fall short if the information going into it is incomplete, inconsistent, scattered across different places, or simply doesn’t exist in a usable format.
That’s why a software implementation can turn into a data project long before the new system goes live.
The Software Can Be Ready Before Your Data Is
We recently worked with a company implementing new software that could help automate its purchasing process. The system had a useful feature: products could be added to an estimate, and once the estimate was signed, the software could use that information to help create the necessary purchase orders.
There was just one small problem…the company didn’t have a complete list of the products it normally purchased. Ok, this was a big problem.
The software was capable of doing what they wanted, but first it needed that data. Fortunately, The Penguin Group co-owner Nesanel Moeller had a simple solution: “Give me your invoices from your vendors from the last two years.”
Using AI, that purchasing history could be turned into structured information: the products the company had purchased, what it had paid, the most recent price, and when each item had last been purchased. That gave the company something it could actually import into the new system.
This is the part of software implementation that is easy to underestimate. Your new platform may be ready for your data, but that doesn’t mean your data is ready for the platform.
Most businesses already have enormous amounts of information. But, it rarely exists in one clean database waiting to be migrated. It might be scattered across spreadsheets, PDFs, invoices, email threads, notes, attachments, old software, and individual employees’ files. Sometimes the information exists, but not in a format that a new system can actually use.
Before you can decide how to configure a new system, you need to understand what information the business actually has, where it lives, and what needs to happen to make it usable.
Follow the Information Through the Business
One useful way to approach an implementation is to temporarily stop thinking about the software and instead walk through the actual business process. What information enters the process? Where does it come from? Who creates it? Where is it stored? Who needs to review it? What decisions depend on it? What happens when something changes?
We saw this in another recent client conversation involving lease management. A lease might begin as a PDF. Information then needs to be entered into the company’s system, reviewed, approved, potentially updated when dates change, activated, and eventually used to generate charges and invoices.
If you look only at the data-entry step, you miss most of the process. The real implementation challenge is understanding how the information moves from the original document through every step that follows.
That understanding should ultimately determine how the software is structured, where information lives, and which parts of the workflow can safely be automated.
This is also why simply migrating everything from an old system into a new one isn’t necessarily the right approach. An implementation is an opportunity to decide what information is still useful, whether it is accurate, how it should be structured, and whether it belongs in the new system at all.
Moving ten years of messy information into a new platform doesn’t make the information better. Sometimes it should be cleaned or restructured. Sometimes historical information should remain accessible without becoming part of the active system. And sometimes it should simply be left behind.
The goal isn’t to recreate your old system inside your new software. It’s to give the new system the information it needs to support a better way of working.
Once Your Data Is Structured, You Can Do More With It
The purchasing project is a good example of how this work can create value beyond the implementation itself. After the historical invoices had been organized, there was an opportunity to use that information for more than building the product library.
Once again, Moeller asked AI: “What patterns do you notice about their purchasing and what could be done better?”
And in his own words: “it spit out gold.”
One of the patterns it uncovered was that the company was sometimes making four or five purchases for the same project.
Think about what that means operationally. A crew could already be working on a job when someone realizes they’re missing an inexpensive item. An employee then has to stop working, get into a vehicle, drive to a supplier, purchase the item, and return.
The missing item might cost $15. The interruption can cost hundreds.
The original goal was simply to create the product data needed for the new software. Once that information was structured, however, it could also be used to understand how the company might purchase more efficiently.
That distinction matters. Good data isn’t only something your software needs. It’s something your business can use.
Poor Data Gets Expensive
Problems with business data can sound abstract until you look at what they actually cost.
IBM reports that more than a quarter of organizations estimate they lose over $5 million annually because of poor data quality, while 7% report losses of $25 million or more. Those costs can surface through inefficiencies, missed opportunities, unreliable analytics, and problems that spread into automated processes.
Those losses don’t necessarily appear on a financial statement under “bad data.” They show up in employees reconciling conflicting information, searching for missing records, correcting mistakes, manually updating multiple systems, fixing broken workflows, and making decisions based on incomplete information.
And the problem becomes particularly relevant when companies invest in sophisticated new systems. McKinsey reported in 2026 that around 65% of advanced planning system programs fail to achieve their expected return on investment. Poor data management was one of the top five reasons identified.
An advanced planning system is a specific type of enterprise software, so that statistic shouldn’t be generalized to every software implementation. But the underlying lesson is relevant: sophisticated technology still depends on the quality and structure of the information feeding it.
Better software cannot indefinitely compensate for bad information.
Get the Structure Right Before You Automate
Data becomes even more important when automation is part of the implementation. Automations depend on fields, statuses, dates, categories, triggers, and other structured information. If those inputs aren’t reliable, the automation won’t be reliable either.
This is why the structure of your information needs to be decided before too much automation is built around it. Otherwise, you can spend time creating workflows only to discover that the underlying structure needs to change. Then the automations connected to that structure may need to change too.
Before configuring a new system, it helps to audit the information the process actually depends on. Identify what information is required, where it currently lives, whether it is accurate and consistently structured, what needs to move into the new system, and how it should be maintained going forward.
This doesn’t need to become a massive data-governance initiative. The goal is simply to understand the information your processes rely on before you start building software around it.
Doing that work upfront can feel slower because the natural impulse is to get into the new platform and start building. In practice, it can prevent a significant amount of rework later and make reporting, integrations, and automation much easier to build.
Better Software Starts With Better Information
A software implementation may look like a technology project from the outside, but underneath, it is often an information project.
The software needs to know who your customers are, what your team is working on, what products you buy, what stage a project is in, what has been approved, what happens next, and thousands of other details specific to the way your company operates. If that information is scattered or unreliable, the software has very little to work with.
There is also an opportunity hidden in that challenge. Getting your data ready for new software forces you to look closely at information your business may have accumulated for years without really using.
Once that information is organized, you may find unnecessary work, purchasing inefficiencies, gaps in your processes, or opportunities to automate that weren’t obvious before.
That’s why a successful implementation shouldn’t simply move a business from one platform to another. It should leave the business with better information, a clearer understanding of how that information moves through the company, and a better way to use it