Support for Windows Server 2003 ends July 14, 2015, and the market has moved from being unaware of the challenge posed for IT organizations to POCs and deciding how to get help with these projects. You can get a sense of how the market has moved by reading the 2014 Windows Server 2003 End of Support Survey Results.
Many organizations have already budgeted modernization projects and will ramp up efforts to move off of Windows Server 2003 and onto Microsoft Azure this year. In fact, Spiceworks' annual IT budget survey showed customers were allocating around 17% of their 2015 software budget to OS migration, with Windows Server 2003 being the prime candidate.
The process of application migration and modernization can be framed in four steps:
- Discover: Catalog the software and applications
- Assess: Categorize the applications
- Target: Identify destinations
- Migrate: Move the application from source (data center) to destination (Azure)
This sequential process makes sense, and has clear transitional steps and a well-defined end state. As organizations adopt this process and put it into practice, detailed feedback emerges. Many projects start with staff devoting lots of time to understanding the entire application portfolio. Then comes interpreting the inventory and assessing how to remediate. Next, the destination is scoped out, and, finally, migration waves begin.
The Migration Waterfall
The projects often resemble the old waterfall process of building software:
- Design the app
- Build the app
- Test the app
- Deploy the app
The premise of the waterfall process is that if you put enough time upfront into the requirements and design phases, then the later phases will be easier, faster, and cheaper to execute. Experience shows that while it would be nice to have a perfect set of requirements defined, it takes so long that the business moves on, making the requirements irrelevant. The process also lacks feedback, plus new details surface toward the end that often materially change the requirements. The outcome of the waterfall app creation process is an unsatisfied user, and so the slow waterfall process starts again. This approach leads to long iteration cycles before feedback is incorporated into the resulting app.
The Agile Approach
Instead of migrating from Windows Server 2003 using a waterfall methodology, organizations should adopt an agile migration approach.
An agile migration approach creates a cross-functional team that takes a slice of the application portfolio and performs the migration process from beginning to end. Once that slice is completed, the next slice is addressed, with the team continuing to gather feedback and improve the process.
In most organizations, IT hardens and locks down the environment, making migrating applications difficult. Migrations cut across disciplines, requiring buy-in and cooperation to smooth and expedite the process. An agile migration team should consist of a cross-disciplinary skill set containing these personnel pieces:
- Server Administrator: Build, Provision AD, Snapshot
- Application Server Developer: Web / Middleware
- DBA: DB Server
- AppZero architect: Migration
This team often has high-level goals such as:
- Create best practices
- Remove "white space" from process
- Increase throughput
- Reduce down time
- Improve problem resolution
- Lessen errors and side effects
Getting the first couple of migrations done with security acceptance and help from all stakeholders is often a big hurdle for large enterprises. An agile approach provides visibility to all interested parties and reveals sticking points that slow the process. Iterating migration waves or sprints, in agile terminology, will identify the bumps that can be removed, increasing throughput. At AppZero, we have been using the agile migration methodology in conjunction with our up-level application migration software to remediate WS2003 applications for the past several months, and we are seeing significant time reductions to these projects.
Migration Process Implementation Challenges
Certain challenges consistently emerge during the migration process, going far beyond the spectrum of the migration itself. These challenges can be sorted into the following categories:
- Size and scope of the problem:
- Applications and servers often are measured in thousands
- Complexity and coordination; many touch points
- Second-order issues: support, down time, policy exceptions (most IT policies are designed to freeze apps/data/configurations, making them immovable)
- Costs grow quickly, leading to more scrutiny and further delays
- Lack of skills and knowledge about application migration
- Ownership of problem resolution delineation between IT and lines of business (app owners)
- Coordination and process crosses disciplines
- Application owner and knowledge is scarce
- Change windows and application handoff result in latency
- Maintenance-driven change activities are difficult to get people excited about
Application-Centric Categorization Taxonomy
An application-centric approach groups like applications together, based on the application platform, how the application is deployed, and how critical the application is. Organizing the portfolio this way is helpful when determining waves or "sprints" for the migration team.
Grouping like applications reduces the upfront time required to assess applications in exhaustive detail. .NET applications have common characteristics from an assessment perspective, including IIS, .NET version, message queues, and database connectivity. Use-case creation can drastically accelerate migration planning and minimize time spent in the assessment phase.
Migrations can begin sooner in concert with ongoing assessment and planning activities. Performing simple migrations at the outset helps shake out environmental challenges and UAT requirements in real time to establish a much-needed baseline and predictive model. Applying the agile approach takes lessons learned and continues to apply them to evolve the migration strategy.