If you’re migrating your Windows 2003 server, you should be following the four major steps to a server migration: discover, assess, target, and migrate. After a thorough discovery process using a variety of automated tools such as The Microsoft Assessment and Planning Toolkit (MAP), you should have a very good idea about your server migration readiness, what problems you need to address with your system before moving forward, and what kind of bandwidth you’ll need to complete the next step.

The assess process will help you organize your workflow for the rest of the server migration process. During the assess phase, you’ll take inventory of everything that needs to be migrated, categorizing it based on priority. By doing this, you’ll then get a full understanding of how you’re going to schedule and manage each piece of the migration. Some applications are easy to migrate, while others are more difficult and therefore take more time.

Once you have a catalog of your system’s allocations and possible technical problems that need to be addressed (and should be addressed before you move on to assessment), you will need to assess what is in that catalog. This means categorizing your applications and workloads, while performing a thorough analysis of what you’re dealing with. The goal of the assess phase is to create an ordered list: what you’re going to migrate, in which stages, and how long it will take for each segment.

Consider categorizing your applications and workloads in four different ways:

  • By Type: Microsoft server roles, Microsoft applications, custom applications, and third-party applications.
  • By Criticality: Can be retired, marginal, important, and mission critical.
  • By Complexity: Low, medium, and high.
  • By Risk: Low, medium, and high.

The categorization will also reveal some potential opportunities in regards to improvements to your systems.

The criticality category, for example, might raise concerns about what to migrate when and in what order. The complexity and cost categories will indicate which migrations might be the easiest and quickest to accomplish while lowering costs.

Analyzing two categories together can provide more insight; for example, an important application with low complexity and only medium risk might be a good candidate for early migration. This will help you break up each piece of your workload, plan out the next phase of your migration, and develop a timeline and task list that is easier to manage.

By moving over pieces in the most logical order, you’ll be able to keep track of how everything is moving, if there are any pieces falling through the cracks, and identify any challenges. It’s after this step that people usually decide how to allocate employee time or whether to bring on additional consultants to help with the migration.

You must choose a migration destination for each application and workload. There are four destinations for migration:

  • Windows Server 2012 R2
  • Microsoft Azure
  • Cloud OS Network
  • Office 365

Depending on the type, your different workloads and applications will logically lead to certain targets. Others could offer the possibility of migration to one or more of these destinations—in which case, you’ll need to weigh the pros and cons before choosing which makes the most sense. Try to keep in mind any future development, tools, or workflows that might influence your decision. The choice of where to migrate an application or workflow will be also driven by speed and ease of migration, cost, and desired functionality in the migration solution.

Once you’ve assessed all of your applications and workflows, you’ll have a good understanding of the work ahead of you. Take this opportunity for project management, let ting it inform your process for how you parse out the workload. If you’ve properly tagged everything on your server according to priority, then you should have no problem with the next phase of the migration process.

The next phase of the migration process is the target phase.