Custom applications are the bane of every Disaster Recovery (DR) professional I know. These applications are almost always vital to the organisation, but are also nearly always badly managed, horribly written, and outdated. While there are exceptions to this generalisation, the majority of custom applications pose a problem when you begin your DR planning.
There are two general categories of issues that custom applications cause in DR planning, and both will have to be assessed and addressed if found. The first is software that is specifically designed (either on purpose or accidentally) to prohibit fast DR. The second is lack of management over the software itself.
Most major software applications are incredibly flexible, meaning that they can adapt to changing circumstances within their environment — within certain limitations of course. Custom applications generally do not follow that form and are often written to work within a very strictly limited set of conditions and environmental variables. While you can easily protect these applications' data with tape backup and basic data replication, they pose an incredible problem when you discuss high availability solutions in your environment. Basically, if a custom app cannot work anywhere except on the exact server for which it has been configured, then you cannot easily move it to another system in the event of a disaster.
The most common DR problem for a custom app is its inability to work on any other IP address or subnet than the one it was originally written for. So, if you attempt to fail over to another data centre, you'll find that the application cannot function, since the alternate data centre will nearly always be on an alternate subnet. You can get around this issue by using a VLAN or other subnet-stretching technologies to make available the IP address that is required when you need to fail over, but these technologies are expensive and complex to implement and manage.
The second common problem that crops up is the lack of proper documentation and management for many custom applications, making them enigmas within their own environments. Employees and technical staffers may know what the application does, but often no one but the application's developers know how it functions. When you attempt to plan for DR, you may find that you have no clue how to properly configure and/or manage this application either for backup or for failover. Where does it keep its data, and what files have to be protected? Can it be backed up while in operation, or does it need to go offline first? Can it be installed on more than one server at a time, or will you have to use advanced failover methods to trick the backup server into thinking it's the production box at the time of the disaster? All of these questions can be answered by the programmers and application developers, but without their input you may find yourself in an impossible DR situation.
Custom applications pose challenges to any organisation, but you can protect them. Bring in the developers, plan according to the needs of the application, and get management buy-in every step of the way. Perhaps the most important thing you can do is determine the criticality of these applications before you begin. Most of them can be backed up to tape or disk rather easily, and if you have a longer period of time to get them back, you can use the backup to restore service to a re-installed machine. This may save you a lot of time and pain when planning for a disaster, or at the very least, let you properly plan for what is no doubt going to be a long process to come.
