Helping retire a large legacy reporting system

The problem

Liberty Mutual was paying more than a million dollars a year in licensing for a reporting platform it wanted to leave. Leaving was not a procurement decision, it was an archaeology project: the reports sat on top of a legacy schema of more than fifteen hundred database tables, accumulated over years, with the business logic encoded in the reports themselves rather than anywhere documented.

You cannot turn that off until every report that anyone depends on exists somewhere else and produces the same numbers.

What I did

I owned the Cognos reporting projects and the rewrite of every existing report onto the new platform.

Mapped before building. The work that made this succeed was unglamorous: in-depth systems analysis to establish what each report actually did, which of those fifteen hundred tables it truly depended on, and — critically — which reports were still load-bearing versus which had simply never been deleted. A migration that faithfully reproduces reports nobody reads is a migration that costs twice what it should.

Built, tested, released. I developed, tested, and released more than a hundred Cognos reports supporting the SAS migration, managing the development, testing, and deployment cycle for each so that the output stood up against the system it was replacing.

Ran the adjacent bets. I also served as analyst on the SAS Visual Analytics pilot and on a separate legacy system retirement project, both of which fed the same strategic direction.

Outcome

The migration delivered the licensing savings — over $1M — and, more usefully, left the organization with a documented understanding of its own reporting estate that it did not have before.

Why it matters

Most of my later product work is a version of this problem: something expensive and entrenched needs replacing, nobody has a complete picture of what depends on it, and the analysis has to come before the roadmap. I learned that here, with the numbers attached.