If you work in IT, or even in a department that is associated with IT, at some point you may be asked to take over a website or web application that you had no part in managing. You may have been in grade school for all that matters when it was installed, but somehow this landed on your plate and you are the go to person when it comes to the site questions. Even if it does not work the way the current world works, it may look like some hideous attempt at something leading edge. So congratulations--you are the proud new owner of a “Legacy Website"!

First things first. Don't panic. Here's a quick and dirty guide to managing the system with the top ten things you need to know to survive.

1. Be sure you can manage the domain information.

  • Domain Register – be sure you have access to the login and that you have updated the contact info to the correct ones.
  • DNS Service – Although the Domain Registrar can provide the DNS service as well. Sometimes your domain name and DNS services are handled by separate vendors.
  • Be sure you are paid up to date. The worst is to have the domain expire and you have to deal with paper work on top.
  • Hosting – Be sure that your website or legacy application is hosted somewhere that is reliable and that it is backing it up! Don’t be shy to ask for a copy of the back-up to test.

2. Inventory the Assets and be sure you can get a copy it.

Keep the copy safe (off site), for a rainy day.

  • Be sure you have the source code.
  • Database (and appropriate login information).
  • Media (Video/images/documents).
  • Installed software (setup files for object and get your hands on the source code if possible).
  • External System requirements.
  • Back in the day, yes interoperability did exist. Your legacy site may still be connecting to some system over the web.

3. Get your hands on documentation (any and all)

  • If you are reading this, most likely you don’t have anything. Start creating it!
  • But, see what you can get. Even getting a sense of the history of the website or features may point you in the right direction when reverse engineering. People know more then they let on, so find out who used the app before and do some CSI investigation work. End user information is way better than nothing. You don’t have the luxury to talk to the person who originally built the site!

4. Hardware requirements

  • What hardware do you need to run the system?
  • Can the website really run in a virtual server? Back then VMs were a bit of voodoo magic.

5. Software requirements

  • Does this thing only work on a particular OS version, or application version?
  • Does this website connect to a database?
  • Do I need to install other software to make things run? There may be some 3rd party objects that have yet to be discovered.

6. Overview diagram

Do you really understand what is going on? Put into a picture, it will help you explain it to other, if not only to help yourself. Create a diagram in Viso or just pen and paper.

7. Licenses

Be sure you have the appropriate license keys. Some time you may have to contact the original vendor to be sure these work if the event you need to recover from a server melt down.

8. Support or Enhance the legacy website?

Supporting and Enhancing are two different things. To support you efforts will be to keep that website or web application running and communicate the strengths and limitations to the users. Because it is legacy does not mean it is not important. To enhance you will need to get your hands dirty and take on some ticking time bombs that are lurking about. If you plan to enhance, it may be worth your while to farm out to a 3rd party vendor if you do not have the internal skill set in house.

9. Patience

These websites were most likely built in a different decade. So some things that don’t make sense now may have made perfect sense back then. So give the old guys a break!

10. Plan for a disaster

Be sure you can recover this system. If you have been designated the person to support this ticking time bomb, it doesn’t hurt to test a restore from scratch scenario. Supporting and Disaster Recovery go hand in hand. If you are lucky to have a separate resource to handle Disaster Recovery be sure both of you are on the same page. Be sure to bring that diagram you made to help explain things.

Keeping these things in mind should help you understand the task that is before you. Good luck!