Securing Systems You're Planning on Replacing

We get used to working around limitations in our tools, because that's what we have to work with. If you’re considering migrating your email, Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) package to a new platform, it’s like buying a new family car- planning for a new future while minimizing your existing expenses.  

Deciding to get rid of that old clunker

There are a couple of steps between idly musing about an ideal new system and actively working on it. Replacing old systems, whether they be cars or applications isn’t an instant process. It starts with the realization that your current situation is untenable in the long run- the car that might not start in the morning or the unsupported application that has needed new functionality for a while.

Repairs, patches and workarounds might be sufficient to keep everything working for a while, but you're taking a risk that the workaround, well, doesn't. Pretty soon, you're doing convoluted things, like running old browsers on a Citrix instance to let your users work with that antiquated CRM. Or you're keeping a spare, charged battery in your trunk in case that electrical fault drained the battery.

Eventually you realize that you're spending more money and effort to keep an unreliable system operating and you start the process of moving on. In order to get buy-in, you have to get requirements from stakeholders.  Everyone will have a wish list for the shiny new possibility. A substantial number ofthe items on the wish list will be negatives- the back seats won't be sticky, the CRM won't require different screensfor contact information and current orders.   

And in this bright shiny moment, you get a reprieve. You'll answer complaints with "we're going to replace that system and everything will be wonderful when it happens". Every trouble ticket or change request will be an impetus to get the replacement live.

Doing this without a workable lifecycle management process is going to be a bumpy ride. To speed the new project, available staff, money and focus will be yanked away from supporting and securing your old system to go to the roll-out of the new one.  

Yet your business relies on the old one. Your critical data runs through it. Losing confidentiality, integrity or availability is still A Bad Thing (tm). You need to spend time, money and effort to keep it safe enough enough while you finish its replacement.

If we can go back to the car analogy, you’renot paying for a new paint job or transmission. You still pay for gas and lock the doors. Brakes and tires will have to be replaced to keep you and your family safe.

How do you determine security expenses to pay for and what to skip for your infrastructure? I’ll break this down by phases:

Planning- This phase starts with deciding to consider replacing your enterprise system and ends with the start of implementation. You’re getting requirements from your stakeholders and comparing vendors for systems and implementation.  You have drafted budgets and timelines.

During this phase, you want to continue normal efforts in securing and maintaining your existing systems. Keep performing the usual patching, testing and evaluation activities. You may find some places to economize by ending or reducing support contracts, but make sure you can still get security and reliability patches.

You’re also going to want to ensure that you’re maintaining these systems from the operational side as well. Make sure you’re keeping track of current users, validating backups and ensuring the accuracy of your data.

So far, so good.

Implementation- This phase starts once you’ve signed contracts and ends with the rollout. You may find that the budgets and timelines you created during the planning phase range from optimistic to laughable.

This is the time you’ll have to be careful. As the implementation phase stretches, you’ll be looking for budget and staff time to throw into preparing the new system. It’s all to easy to say “It’s a small risk to leave the old system unpatched for a month or two”.  

Fight that urge. One or two months can turn into six as the implementation drags on. That’s time that your crucial system is vulnerable. Keep maintaining those systems like you rely on them, because you do.

Rollout- Your new, shiny system is ready for your users. Every staff and consultant will be needed to make sure the rollout goes well, lest users be unhappy with it.

This is when you can start slowing down. You may want to hold off on application patching and maintenance for this phase, if only to reduce the risk that a patch makes data unavailable.

If you do an overlapped cutover, where some users keep access to both systems for reporting or historical reasons, you’re going to want to maintain the system as if it was still in the Implementation phase, until you no longer need it.

If the cutover isn’t overlapped, you’re going to want to prepare the system for archival. You’ll need to determine how long you need to keep the data. Check with your policy or legal counsel to identify when you no longer need to keep the data around.

You don’t want to just keep the data. You need the capability to make it viewable again. If the system needs a certain operating system or application to operate, keep that on-hand just in case. This may be as easy as saving an image of the virtual machines that supported it or as difficult as keeping old hardware around.

Just because it’s archived doesn’t mean it’s inaccessible. That data may still be sensitive. You’re going to want to track it and put appropriate controls around it to make sure you don’t suffer a breach.

Conclusion

All this may seem to make a cutover more difficult than it needs to be. But instead, these steps will keep your systems, data and organization safer through the entire project lifecycle.

If you’re a more mature shop, consider how well your lifecycle management policies and procedures

And one fewer worry about your data is a good thing during a crucial rollout.