Migrating 300 Legacy Systems to One EHS Platform: Lessons from the Trenches

A few years ago, I led a project to consolidate over 300 legacy EHS data systems and applications into a single enterprise platform for a large manufacturer. The kind of project that looks clean on a slide deck and is chaos on the ground.

The legacy systems had accumulated over decades. Spreadsheets. Access databases. Homegrown web apps. Paper forms that got scanned into SharePoint folders. Each facility had its own way of tracking hazardous waste, safety incidents, chemical inventories, and training records. Some of it was good. A lot of it was a mess.

Here's what that project taught me.

Nobody Knows What They Have

The discovery phase took longer than anyone expected. We'd ask a site: "What systems do you use for EHS tracking?" They'd name two or three. Then we'd dig in and find eight more — some maintained by people who had left the company years ago, some that only one person knew how to use, some that were technically "retired" but still had data people relied on.

Before you can migrate anything, you need a complete inventory of what exists. And I mean complete. Not what's in the IT asset registry. What people are actually using, day to day, on the ground. Those are different lists.

Data Doesn't Translate Cleanly

Every legacy system stored data its own way. Different field names for the same thing. Different units. Different date formats. Chemical names spelled three different ways across five databases. One site tracked waste in pounds, another in kilograms, another in cubic yards.

We spent months building crosswalks and transformation rules. And even then, there were edge cases that required manual review. The temptation is to automate everything, but some data problems can only be solved by a person who understands the context. You need both.

Change Management Is the Actual Project

The technology part — configuring the platform, building integrations, migrating data — is maybe 40% of the work. The other 60% is getting people to use it.

Facility EHS managers who have been tracking incidents in their own spreadsheet for 15 years are not going to switch to a new system because someone in corporate said so. They need to see that the new system actually works for them. That it saves time, not adds it. That their data didn't get lost. That the reports they need still come out right.

We did this through a combination of hands-on training, site visits, and — honestly — just listening to the complaints and fixing the issues that came up. The people on the ground will tell you what's broken. Your job is to listen and respond fast enough that they don't lose faith in the system.

Scope Will Change. Plan for It.

We started with a defined scope: migrate specific modules for specific sites by specific dates. Within six months, three things happened: the vendor released a major update that changed the UI, two sites got added to the rollout ahead of schedule because of a regulatory deadline, and one key team member left the company.

If you build your project plan with zero margin, any one of these kills your timeline. Build in buffers. Have contingency plans. And manage scope changes through a formal process, even if it feels bureaucratic. "Scope creep" sounds mild. In practice, it's the thing that turns a 12-month project into a 24-month one.

The Result Is Worth It

When it's done, and everyone is on one system, the value becomes obvious. Reporting that used to take weeks takes hours. Data quality improves because there's one source of truth. Cross-site comparisons become possible for the first time. Leadership gets dashboards instead of email attachments.

But getting there requires patience, executive support, and a willingness to get into the weeds with every site that's struggling. It's a grind. And it's worth it.