Managing Technical Debt and Legacy Websites

July 30, 2015

IEG has produced over 150 distinct web properties over the last two decades. This large collection of sites requires ongoing maintenance or pieces of those sites will break at some point, as they accumulate technical debt.

What is Technical Debt?

Technical debt is a metaphor referring to the debt created from legacy systems and long-maintained architectures. If the debt is not repaid by correcting the suboptimal solution, it will continue to accumulate interest. This interest takes the form of increasing complications when trying to resolve or repay. Migrations are the collections agencies for technical debt.

“Implementing Service Oriented Architectures”
Bradley Clerkin – Solution Principal @ Slalom
AWS Summit NY, July 8

We have accumulated so many websites over the past twenty years, we now have thousands of pages left online, left untouched. We have to decide what is best for those sites. Should they be kept online, or retired and removed from the web?

Broadcast Companion Sites

Most of our web properties are broadcast companion sites. Our flagship episodic programs on PBS include Nature, American Masters, Great Performances, Religion and Ethics Newsweekly, and Secrets of the Dead. These programs have a well-tuned web production process. Content is added on an ongoing basis, and they are periodically redesigned and upgraded with new features and technology. The same is true for our station sites,,, and

However, the majority of our broadcast companion sites are built for stand-alone or miniseries programs. In the past, these sites have been funded, built, launched, and then generally neglected a few months after the initial program run, as new projects roll in and the cycle begins again. Over time, they all ultimately break in some fashion. If it’s not an interactive or a script, it’s the page layout breaking as browsers evolve, or the images and video shrinking as display size and PPI continue to grow. These are the sites that accumulate most of the technical debt.

Greenfield Versus Legacy
Who doesn’t want to work on greenfield projects? You get to use the latest and greatest tools, with no constraints from legacy infrastructure. You can use everything you’ve learned from previous projects, and make better architectural decisions. You don’t have to migrate content from a square peg to a round hole. You don’t have to train and retrain users who have committed painstaking workarounds for the legacy system into muscle memory. As the old joke goes, “How did G*d create the world in 6 days? No legacy infrastructure and no users.” Unfortunately, unless you’re working for a startup, you’ll probably have to deal with a mountain of legacy code and content. However, you may be able to reduce the size of that mountain before you move it.

Retiring Sites and Evergreening

We are currently working through a list of 63 legacy web sites from our pre-WordPress era, stretching all the way back to 1997. They are mostly static HTML, with a few interactives. All no longer have budgets (see below) and will require significant work to update to current best practices. We are using the following criteria to determine what to keep and what to drop:

  • High traffic
  • High search results
  • Video availability
  • Unique content
  • Value to internal stakeholders

The more sites we drop, the lower the technical debt we retain when we visit the remaining sites in the future. For the sites we keep, we drop features that would be too expensive to update. We “evergreen” the site by disabling social media and other time-sensitive widgets. We then add a banner that says “This website is no longer actively maintained. Some material and features may be unavailable.”

Recommendations for Project Life Cycle and Technical Debt

I recommend life cycle planning that accounts for technical debt for every project. This needs to happen at every phase of a project, including grant proposals, scope of work, contracts, and service agreements. If applicable, grant terms should be taken into account first; asset licensing should be taken into account next. For example, if the primary content of a site is online video and the rights are secured for five years after launch, the life cycle of the project is five years. A date to take down the site along with the video should be in the contract, along with a line item in the budget. If the non-video content should be left online, that should also be specified from the start, as the life cycle will include a post-video phase.

Finally, ongoing routine maintenance, technical upgrades (e.g. WordPress, PHP, etc.), hosting, archiving the content after the site goes offline, and all other post-launch costs and resources must all be considered as early as possible in the planning process. These facts should be clearly specified for the entire time the project requires any resources. This level of detail will improve long term budget accuracy for the project, and provide clarity and direction for the often neglected post launch, retirement, and archive phases.

The opinions expressed in this post represent those of the individual author, Brian Patrick Lee, and not those of Digital at The WNET Group.