One important dimension of security for legacy systems involves strategies for migrating to systems that are more inherently secure. In this context, it is often the case that a migration strategy needs only to preserve existing assets. For example, a user may have a large investment in data files of a given format that are required for a given version of a program. A new version that is more inherently secure may well require files of a different format. One strategy to preserve assets may be to require the new version to open all files in the old format. A different strategy may call for a conversion utility to convert old files to the new format.

The first strategy might be deemed a requirement for backward compatibility—that is, the new system should operate as the old one did in a manner that is as transparent as possible to the user. But all too often, the requirement for full backward compatibility complicates the security problem—backward compatibility may, explicitly or implicitly, call for building in the same security vulnerabilities in an attempt to preserve the same functional behavior. (For example, a large fraction of the Windows XP system code base is included for backward compatibility with Windows 98 and Windows 2000—a fact that is well recognized as being responsible for many vulnerabilities in XP.)

In the second approach, the migration to a more secure system is made easier by the weaker requirement that only the data assets of the earlier generation be preserved (or made usable) for the new system. The duplication of all functional behavior is explicitly not a requirement for this approach, although it remains a significant intellectual challenge to determine what functional behavior must and must not carry over to the new system.

Another fact about system migration is that with distributed systems in place, it is very difficult, from both a cost and a deployment standpoint, to replace all the legacy equipment at once. This means that for practical purposes, an organization may well be operating with a heterogeneous information technology environment—which means that the parts that have not been replaced are likely still vulnerable, and their interconnection to the parts that have been replaced may make even the new components vulnerable. The result of this tension is often that no meaningful action for security improvement takes place.