Top tips for confidently migrating applications to software-defined networks

Migrating business applications to SDN environments can be daunting, but businesses can gain SDN confidence with the right preparation and management plan

Related topics
Networks
Software

Related articles

Why SDN and NFV make perfect partners in the software-defined data centre
Keeping the pace: five reasons why software-defined networking will get businesses back on track
Is the enterprise still not ready for the software-defined data centre?

Share article

Short of time?

Print this pageEmail article

A step-by-step migration can help ease the transition to SDN

Software-defined networking (SDN) is one of the hottest trends in security and networking. Many enterprises are considering moving to virtualised networks such as VMware NSX as part of an overall shift from relatively inflexible hardware-based architectures to nimbler, faster, more scalable virtualised deployments.

For most companies, the question is increasingly becoming how and when, rather than if they adopt a more software-centric networking model.

SDN offers several potential benefits to organisations, including cost reduction, centralised management, quicker application deployment, scalability and reduced downtime. Security is also a key benefit, as SDN allows you to more easily define internal network segments and then filter East-West traffic. 

However, migration to SDN can seem daunting for CIOs given the resources and money they have already spent on their current infrastructure. Whether they’re using SDN to supplement or replace their traditional network, they want to be confident that the benefits of the new technology will justify the resources and risks involved in the deployment.

> See also: Why the future of storage is software-defined

Any migration requires careful planning and management, so here are a few tips to help ensure you transition your business applications smoothly to SDN.

Setting your objectives

Before beginning the migration process, organisations need to think about their reasons for choosing to go the SDN route and what they want to get out of it.  Different organisations will have different reasons and goals for migrating their applications to SDN and will apply the concept in different ways.

They may be looking to centralise their network management, improve security or simply reduce costs. The objectives of the deployment will determine the technical process, so successful planning, identification of goals, and analysis of how the migration could impact business continuity, are crucial to the success of a migration.

Discovering application connectivity

A crucial aspect of this pre-migration planning phase is discovering and mapping the connectivity flows of your business applications. This process is imperative because you need to know the existing flows in order to make the necessary changes to them when you migrate to SDN.

Unfortunately, the complexity of modern networks makes this a very challenging task. Disciplined organisations that maintain accurate, up-to-date, machine-readable records of the traffic flows that support each business application can quickly start the migration process by importing their documentation. 

More often than not, the application discovery stage will combine all available data sources: importing data from CMDB or home-grown repositories, machine-assisted discovery from traditional firewall policies, and intelligent traffic-based application connectivity flow discovery.

The migration process

Once you have planned your migration process and successfully discovered the traffic flows for the applications you wish to migrate, you are ready to move them to a software-defined network. However, this is not something you can do overnight. 

The work involved in application migrations can vary depending on the size and complexity of the network, and on what the organisation is looking to get out of the project, so it is advisable to take a gradual, step-by-step approach. You will not be able to migrate all your applications at once, so be prepared for a stepwise, ongoing migration process. This will usually include the following stages:

Allocating IP addresses and assigning the server workloads onto the new addresses; reconfiguring the application software to use the new IP addresses; writing new policies to allow the application’s discovered traffic; deploying and validating the policy; testing the application’s functionality; moving the application to production, and decommissioning the legacy version of the application connectivity

Managing the network

Once you have completed the migration of your applications to the software-defined network, your IT department should be prepared for ongoing security policy management.

They will need access to change tracking and audit, risk and compliance reporting, as well as be able to modify the new network policies in accordance with changes to business applications.

> See also: Why SDN and NFV make perfect partners

The best way to manage this is with a holistic, automated change-request system that supports both the software-defined network firewalls and security controls, as well as the traditional firewall estate.

Migrating to SDN is also a good opportunity to reduce clutter and improve your policy efficiency. You should only convert actively used rules to the new network - in fact, a good migration solution will automatically flag redundant firewall rules for you.

Overall, a SDN migration project will require a strong, repeatable process to ensure success.  Don’t believe any vendor that promises a ‘silver bullet’ solution that automatically converts everything for you at a click of a button. 

And while automation is crucial for the success of the project, there is no way around the fact that you will still need to discover, model, migrate, and test business applications in digestible chunks.

However, with proper planning, testing and management, organisations can quickly and smoothly migrate their applications, and reap the performance scalability benefits of software-defined networking.

Sourced from Professor Avishai Wool, CTO, AlgoSec