L2 and legacy apps: a lifeline for 2005-era ERPs

Legacy apps with hard-coded IPs are the main obstacle to clean DR. An L2 tunnel makes them recoverable without rewriting them.

2 min read

TL;DR

Legacy applications with hard-coded IPs are the main obstacle to clean DR. An L2 tunnel makes them recoverable without recompiling, without rewriting, without calling the software vendor who often no longer exists.

The 2005-era ERP problem

Pre-2010 Italian software, especially in specific sectors (industrial, distribution, private healthcare), often has:

  • database IP hard-coded in config files;
  • print server IP wired into compiled code;
  • hard-coded NetBIOS names;
  • RPC calls with static endpoints.

In Layer 3 DR, every IP change breaks these apps. Fixing them requires:

  • recompilation (if you have source);
  • calling the vendor (if they still exist);
  • manual workarounds (DNS mappings, modified hosts files, etc).

Time: hours or days.

The L2 solution

With an L2 tunnel the IP does not change. The legacy app boots in the cloud, connects to its targets with the same IPs as always, works without changes.

Extra time: zero.

Typical cases where L2 saves you

1. Pre-2010 accounting ERPs

Software with DB IP hard-coded in db.ini or equivalent. Layer 3 = manual reconfiguration. L2 = works immediately.

2. Access control systems

Access control panels configured with static server IP. Layer 3 = each device must be reconfigured. L2 = unchanged.

3. Network printers and IoT

Static default gateway configuration. Layer 3 = must be reconfigured. L2 = no intervention.

4. Apps with IP-based licensing

Some software has licences tied to MAC or server IP. With L2 the licensing keeps working.

5. Legacy Active Directory

DCs with replicas configured by IP. IP change = replicas to redo. With L2 = unchanged.

The DNS workaround limit

Many projects try to fix hard-coded IPs with hosts files or modified DNS. It works for apps that DNS-lookup on every connection, does not work for those that cache the IP at first start.

For legacy apps it is a coin flip. L2 removes the risk.

When L2 is not enough

  • applications requiring MAC-based clustering with heavy multicast;
  • software with physical hardware dependencies (USB, dongles);
  • systems with hardware licences (HASP keys).

In these cases an on-prem secondary site is needed.

FAQ

Do legacy apps run "the same" in the cloud?

Yes, if the recovered VM has the same resources (CPU, RAM, storage). Sefthy verifies during onboarding.

Does it work for very old legacy (Windows 2003)?

Yes, but watch security: Windows 2003 in the cloud must be segregated.


For the L2 pillar, L2 tunnel for DR. For DNS-free failover, Failover without DNS changes.

Want to see Sefthy in action?

Same IP, same subnet, RTO in minutes. Try it free for 7 days or talk to one of our specialists.