In the article below, Zirrus One CTO, Nathan Vineyard, breaks down migration methodology by asking key questions surrounding the environment and using a phased approach.
Last week during a meeting with a potential client, we were asked a question that I was not expecting. As such, I gave an answer that I wish I could “re-do”. The question was completely reasonable, and while I have performed the activity a thousand times, I didn’t have a great answer in the bag. I needed one that could be called upon for any corporate environment, one that hits all the talking points the customer wants without getting too detailed to send their eyes to the ceiling.
The question: “What is your methodology for application migration?”. Very applicable question that will be answered within this article, but what came out during the meeting was a bit of a ramble as in reality, it depends on the environment. What is the application that we are migrating? Where does the application live? What is the operating system, database type, application type and number of external integration points? In order to answer this question appropriately, we need to think about this in several phases:
Discovery
Planning & Proof of Concept
Implementation & Testing
Documentation & Maintenance
Discovery
The first phase requires an understanding of the current performance or Baseline of the application. We need to understand not only how the customer “believes” the application is responding, but we also need to capture metrics to provide minimum performance benchmarks to use before and after the move. What are the current peak & average:
Application response times?
Number of concurrent users?
Rates of error?
The second key focal point must be the actual current computing infrastructure and the new environment(s). As customers are migrating more often towards cloud based infrastructure, it’s important to know what the current footprint is and what the target environment will require to meet the future demand. Using cloud resources that scale as needed helps an organization during peak usage, but also has the potential to hinder performance or rack up unnecessary expenses if not built correctly.
Planning & Proof of Concept
The next item will be called out by every network and security expert as being too low in the priority chain. Once the high level design (HLD) has been completed, then you should reach out to the security team, absorb the lecture that they didn’t know about this project until now, how they should be the first team involved in the design and apologize. Once the design is complete and firewalls are opened, you need to test immediately. Be prepared for a midnight maintenance to avoid many delays as every firewall edit starts with “It’s done and will work.” After tests are run and fail “Try it now” is hopefully only heard once and we can move beyond. This process can take a long time so take the sarcasm with a grain of salt and buy the beers needed to get the project completed.
The next area that needs review and test are the current integration points. Most applications today are using some type of web service interface (RESTful, SOAP) in order to exchange data. Knowing where these exist is absolutely critical for a migration project to be successful. Often there are applications with many dependencies, so analyze all traffic to make sure you have all traffic covered. Tools exist to help this process as more often than not failures in migrations occur due to some unknown dependency not identified and losing access. Sounds like a simple fix, but it’s far too frequently missed. Once you are confident that you have all data sources identified, documented and properly tested, it’s time to move on.
Implementation
Now that we’ve established the applications that need to be moved and opened the security doors, it’s time to select the priority list and software necessary to migrate the applications. There are several programs that exist for every application type, but there is no single application that works across all platforms. Some of the latest and most advanced don’t cover necessary and extremely popular customer environments such as the hypervisor of choice. Find this out early and mirror against the priority list. Seems simple, but often is overlooked and change orders late in the process are embarrassing (so I’m told…).
Decouple the application (if possible)! Depending on the size and scale of the application it’s important to not try to boil the ocean. So much like the troubleshooting philosophy of KISS (keep it simple stupid) it’s equally important to utilize a similar approach in application migration to minimize moving parts. It’s like my dad has said 1,000 times, the more things move the more things are going to break. So decouple the application from the data and any integration dependencies to move the application first, then bring along the back office systems.
Documentation & Maintenance
Document, approvals, test, migrate, document… So this process is important in any migration, but the specifics vary dependent on the organization. I’ve been involved with large scale projects that required months of notice for any changes. It’s painful, especially for those (like me) with ADD, but following process has to be done. When I was on a project for a company, rhymes with moogle, we would document for weeks for changes that took hours. But the deployment was always successful, the approvals were a snap, testing never failed and the final documentation took little to no time. If you get everything done on the front end, then the back end clean up is minimal. This also will save you time once the migration has been completed as the maintenance can be performed by (almost) anyone in the organization. Save yourself time, energy and partner criticism by making sure the operations teams can find the answers needed before going to the expert.
In summary, would I say that we have a specific application migration plan in place? Probably not, as it depends on the specifics of the environment. But what I will say is that we have done this throughout the years enough to know what makes a project successful and what leaves a bad taste in the CIO’s mouth. Just to be clear, moving an application in typical Lift & Shift scenarios is not a glory seeking opportunity. Everyone expects this to just work without fail. It’s like the usher at a wedding in that you’re doing all the work and in the end, you have no date to dance with. But know if you’re not successful in this critical role then you’re running the risk of wrecking a major event.