Legacy platform modernization

Problem

Software-delivery teams depended on a legacy deployment API built on outdated technology that no longer met current platform requirements. It had to be modernized without disrupting the teams using it.

My role

After some early shared work, I became the primary implementer, technical lead, and subject-matter expert. I wrote most of the implementation and nearly all of the documentation, and I handled the conversations with software-delivery teams, release coordination, business validation, issue diagnosis, and every decision to release or roll back.

I also directed three college interns for six weeks on an associated UI. I set priorities, assigned and reviewed their work, adjusted scope, and walked them through investigations over screen share until they were troubleshooting more independently. Their UI reached production.

How it shipped

We released one or two endpoints at a time while the legacy implementation stayed available. Users validated the new behavior, and I decided whether to continue or roll back. Twice, I rolled back:

• A timeout that the old system also had. Matching the legacy behavior wasn’t an acceptable modernization result, so I rolled back, found unnecessary SQL joins that made the work grow dramatically, removed them, and re-released a few days later.
• Missing schedules and incorrect statuses. I rolled back, traced the errors to how stored procedures had been translated, fixed them, and re-released a few days later.

Outcome

About 12 endpoints and 17 stored procedures were modernized and reached production, and the legacy implementation was retired. One endpoint that previously timed out when processing more than 50 items now responds in under a second.