Senior Director of Solution Architecture
Not too long ago, a question was asked during one of my presentations on migration technology and best practices. The attendee asked, “What is the impact of not doing a proper Discovery?” Running large migration projects starting in 2005, this question pops up from time to time: What is really being asked is, “Is a Discovery necessary?” But a better question is, “What roll does discovery planning play within the migration process and what would a proper discovery process look like in the context of migration planning?”
Arguably, the discovery phase is the most important phase since that’s where you’ll find all the dependencies your application needs in order to run. Without discovery, you are setting your migration up for FAILURE.
From infrastructure components to server and application dependencies, your application has requirements that must be duplicated at the target destination in order for it to run as it did in the source of origin. The discovery phase must provide accurate, timely, and relevant data that addresses both functional and non-functional architectural requirements in order to form a cohesive migration plan. Let’s go over some of these in detail.
Not All Data Collection is Alike
First off, let’s discuss accuracy and data relevancy. I’ve had customers who said they don’t need a discovery phase since they have a Customer Management Database system or CMDB which already has application and server information. Hearing this for the first time is gleefully encouraging but one gets jaded very quickly when one learns that the data is so old as to be unusable. Or worse, it is inaccurate to the point where it is misrepresenting the environment it purports to represent. This happens regularly. But let’s say that the data is kept up to date and accurate. Is it relevant data? Meaning, is the data appropriate for migration planning? When you are planning a migration, you’ll need to know functional requirements such as host firewall rules, software along with hardware inventory, backend database affinities, along with utilization data for capacity planning, upstream and downstream servers, load balancer configurations, SSL certification requirements, and on and on. And those are just some of the functional requirements, we’ll talk about non-functional requirements later.
How Timely is Your Data?
Secondly, let’s also talk about timely data. The data used for planning a migration must be fresh. Not only up to date but the collection process must also be easily deployed and managed by a small staff. A good data collector doesn’t need an army to run it unless there is no other way to make it function. I’ve seen bulky collection teams spend months and months trying to deploy cumbersome software only to find out that most of the bells and whistles weren’t necessary or didn’t completely capture what was necessary. SNMP infrastructure takes too long to configure and NetFlows, for packet captures, collect far too much than is necessary.
In the end, the migration architect determines what is necessary. Having deployment durations, running for 30-45 days is best and that does not include the deployment timeframe. Therefore, when planning a discovery phase, always include the setup time. After that, the clock starts ticking. Why 30-45 days? It seems arbitrary but keep in mind that the more samples in the data set, the better conclusions can be drawn from analysis. Plus, 30-45 days catches batch processing, prevalent in most environments. Durations lasting longer become redundant.
But capturing application and server forensics only gives you part of the story. The captured data needs to be married with Business Intelligence that no software can collect. This is where application owner workshops come into play.
Why You Need to Include Business Intelligence
Thirdly, it’s important to note that capturing data on utilization, software and hardware inventory, along with affinity connection information doesn’t exists in a vacuum. These compute components serve the needs of the application which ultimately serves the business and it is the business that must be included in application owner workshops. Including application owners into the discovery phase means that you are combining business intelligence and hard data to form a Wave Plan. In your Wave Plan, you’ll need to include non-functional requirements that no software technology can produce.
For planning, you’ll need to prevail upon the business and application owners such items as blackout periods when no migrations can take place, User Acceptance Plans, uptime requirements to plan your migration window, Service Level Agreements or SLAs to plan for high availability infrastructure at the destination environment, and so on. Depending upon whether the project calls for like for like, an optimization, or even an outsourcing program will determine the length and breadth of the questions. But suffice it to say, these conversations much take place in order to have a cogent wave plan.
Pulling It All Together
Finally, a good discovery phase leverages automation: intelligent software that will automatically capture functional requirements to be matched with non-functional dependencies in a timely and accurate manner. When the discovery phase completes, the migration architect has all that is necessary to perform an analysis and draw conclusions to determine which applications and servers belong in the appropriate move groups based upon significant factors. These factors are affinity relationships, target environment readiness (perhaps physical servers and appliances such as load balancers must be ordered, taking time), environment priority (non-prod migrating first before production, etc.), and application owner readiness. From the analysis, move groups are formed. The next element is creating the Wave Plan.
The wave plan is much broader in scope than move groups. While move groups combine all the servers that must move together in a single migration window, the Wave Plan has more; much more. The wave plan can include many move groups. For example, SAP can be a single wave with multiple move groups comprising non-production move groups, move groups for external facing interfaces, and finally production. The Wave Plan also includes capacity planning elements required to support the incoming compute components such as physical resources and configuration requirements if the target I physical. Also, the virtual target platform needs to be built and capacity provided as instructed in the Wave Plan. Beyond even the target platform on where the source images will land, the infrastructure requirements must be addressed in the Wave Plan. For example, DNS entries, Load Balancer information, Firewall entries, VLAN destination, Target IP, DNS, WINS, and so on must all be in the Wave Plan lest some items be forgotten.
In Summary, When you consider all the planning involved for a successful migration where nothing is left to chance, why would anyone want to bypass discovery?
See the original feature on Arrow Cloud Journal Here