Microsoft Migration Planning Process, Part 1: "Why Migrate?"


Scott Andersen
Solutions Architect U.S.-MCS Midwest
Microsoft Corporation

Microsoft Exchange Product Group Contributors

Lou Mandich
Karl Sand

Microsoft Field Contributors

David Brandt, U.S.-DesertMtn-STU
Christian Budisusetia, ID-ICON Enterprise
Bernd Vellguth, DE-EPG Technical Sales—BG
Walson Lee, U.S.-MCS East COE Dlv
Jurgen Dohl, EMEA-MCS Germany
John Gilbert, U.S.-MCS Central

June 2007

Applies to:

Summary: An old proverb begins, "The journey of a thousand steps begins with the first." The goal of this white paper is to present the concept of migration in a generic sense, and then to show a specific migration model using this process based on a migration of a customer from Lotus Domino to Microsoft technologies. (19 printed pages)


Executive Summary
Problem Statement
Microsoft Migration Planning Process (MMPP)
Why Migrate?
How Do We Migrate?
What Do We Migrate?
Example Migration: Planning a Lotus Domino Migration
Phase I of the MMPP: Current-State Assessment (Applied to Our Lotus Notes Migration Example)


A customer once asked me, "Is the most successful migration the one that finishes, or the one that never finishes?" I answered, "The one that finishes first." The customer looked at me for a moment and then asked, "Why?" I thought about that for a long time.

Why is a finished migration better than an unfinished or a never-finishing migration?

Simply put, no organization can sustain constant change. They eventually will collapse under the weight of the very solution that they are trying to deploy. But, truly, do migrations really end? Version one of a migration might be the solution that then is repacked (and remigrated) by version two, and so on.

The question of migrations and do they ever end has presented itself time and time again. Sure, the activities and components cease at some point. But does the migration process itself ever end? The next time that customer and I got together was at an event at our office. This time, I asked him the question, "Can migrations ever truly end?" He looked at me and said, "Of course." I replied with a simple, "How?" and wandered off in search of the last migration that I would ever do!

Executive Summary

Migration is a funny word. To a migratory bird, it can mean stretching to the very edge of endurance. At times, birds can fly as many as 2,000 miles over open water. Yet, every year, birds perform this migration process. Somehow, in the IT space, migrations have become something to fear. Migrations in and of themselves contain risk: both technology- and process-based. How you approach the migration planning will dictate both the risk that you will incur and how that risk will affect your organization. Process drives the overall success of the migration and the eventual reduction of risk. How you approach your migration can lead you ultimately to the reduction of the overall risk and a successful migration, too.

This document represents the first in a series of three documents. It deals with the first step into migration planning: the overall process around why you should migrate. Part 2, "In-Depth Review or Current-State Assessment," deals with the information that we must gather to succeed. Part 3, "Plan, Build, and Succeed," takes us from information-gathering to migration.

The goal of this first white paper is to present the concept of migration in a generic sense, and then to show a specific migration model using this process based on a migration of a customer from Lotus Domino to Microsoft technologies.

From a high level, there are several components of a migration to consider:

  • Why migrate?
  • How will we migrate?
  • What are we migrating?

The two key tenets that we will drive through our process are to:

  • Minimize data loss.
  • Minimize impact on the business.

The key in the process is to evaluate carefully what the impact of the change that is being considered will be. If the organization can save millions of dollars, or drive millions of dollars in new revenue upon completion of the migration, it's not as difficult for the organization to accept and embrace a migration. All of this goes to the simple concept of return on investment (ROI).

Problem Statement

The initial risk within a migration is the overall factor of cost. This cost problem can manifest itself during a migration in the following ways:

  • Reduced productivity for end users
  • Increased IT cost and increased time to solution
  • Increased total cost of ownership and reduced ROI
  • Increased end-user training costs
  • Increased end-user turnover
  • Increased infrastructure requirements (bandwidth/servers)

This cost basis is the reason that many organizations stay away from migrations—content, instead, to remain on an older platform that does not provide them with the opportunities for process improvement and cost reduction that a newer platform would.

Microsoft has developed a broad framework for migrations—based on leading frameworks (such as Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), and others) and called the Microsoft Migration Planning Process (MMPP)—that provides an overall process for the migration-planning process. Mapping MMPP process to MSF, it fits into the envisioning phase of an MSF engagement. The four phases of the MMPP are detailed in the following section.

Microsoft Migration Planning Process (MMPP)

The following is a road map for the MMPP.

Phase I: Planning

  • Business justification or business-case development
  • Automated tools:
  • Determine unused applications.
  • Determine duplicate applications.
  • Determine applications that can be consolidated.
  • Determine underused applications.
  • Determine security settings.
  • Migration risk analysis
  • Surveys:
  • IT (current-state network)
  • IT (current-state applications)
  • IT (current-state network services)
  • End users
  • Business owners
  • Remote location IT
  • Interviews:
  • Architecture team
  • Server-administration team
  • Domino development team
  • Business-process owners

Additional Resources During Phase I

Phase II: Preparing

  • Application criteria:
  • Leave in place (do not migrate from the old system).
  • Buy versus build.
  • Use existing third-party software.
  • Expand existing applications (internal).
  • Develop information life cycle.
  • Develop technology life cycle.
  • E-mail system evaluation.
  • Directory evaluation.
  • Gap analysis.
  • Business-function and functionality reviews.

Phase III: Coexisting

  • Apply the criteria to the applications.
    • Begin storage-mapping process (taking current applications and mapping the functionality to a new technology).
    • Create directory-migration plan.
    • Create messaging-migration plan.
    • Create capabilities map (including net new capabilities) using Motion or similar methodology.
    • Create collaboration architecture (straw man).
    • Create messaging architecture (straw man).
    • Create directory architecture (straw man).
    • Create vision scope for proof-of-concept (POC):
  • Document success criteria.
  • Document expected tests and components.

Phase IV: Migrating

  • Create migration and capabilities timeline.
  • Create application-migration plan.
  • Finalize high-level "to-be" architecture.
  • Perform necessary POCs.
  • Document POC success.


From a broad perspective, migrations represent both risk and reward for an organization: risk, in the sense that change, in and of itself, can affect an organization; reward, in the sense that new functionality and options can greatly reduce the cost for the organization, while increasing the overall productivity of the organization. MMPP represents both a broad framework (from which you take and leverage the components that apply to your migration) and a more focused process (step-by-step and iterative, as the migration moves forward). For this white paper, we have selected a migration from Lotus Domino to Microsoft technologies to show off the full breadth of both the broader assessment framework and the more detailed delivery of the migration process.

This MMPP example comes out of a large number of Lotus Domino migrations over a number of years (100 migrations since 1997). It came out of influences including the Microsoft Solutions Framework (MSF), the Perspective Based Architecture approach (PBA), and its predecessor the Application Analysis Envisioning Process (AAEP). The process to develop MMPP was originally wholly focused on Lotus Notes/Lotus Domino Migrations. Over time, it became clear that it would benefit the broader migration process for all technologies. One of the primary reasons for this broader framework is the change in migration tools and processes over the past several years. Migrations were once monoliths that prohibited organizations from moving forward. They were huge projects that spanned years and resulted in both cost and risk for the organization. Although still often true for very large organizations, often we can now consider the various components of a migration as smaller, more focused projects.

As stated, MMPP was originally a migration process built to help Lotus Domino customers consider their options in moving from Lotus Domino to another technology stack. From this broad process came some core migration concepts that are critical, such as:

  • Who originally deployed the solution, and why?
  • What changes have been made from the original solution?
  • How does the organization make money today? Which of the processes that contribute to the financial success of the organization leverage technology?
  • Where does this organization want to be in two, five, or more years?

This allows us both to determine what must be replaced and what the risks are in that replacement. For example, in the bucket "how the organization uses technology," there might be limiting factors that would cause a migration to fail, such as if the entire process for everything the organization does to make money is embedded in one technology. While it is rare for an organization to have invested everything in one technology, it does happen. Add that to a "risk-averse" or "change-averse" environment, and you see why many organizations opt for the "leave-in-place" process. A gradual migration process would be called for in this scenario. One of the components of the original process (AAEP) was an envisioning or discovery process. This process sought to define the as-is state of the origination prior to planning a migration.

Another interesting concept is "what is deployed today." In this case, you have a business that is interested in migration, but has deployed a best-of-breed solution for virtually everything. What they seek now is a migration process to produce harmony. Is this case, the legacy systems become a critical driver for the migration. This migration might even need a broader business-process reengineering aspect, in addition to the realignment of technology.

Having determined the needs and the current state, you can look at the goal for a deployment. No technology was ever deployed just to deploy a technology. A limiting factor here is that organizations often consider deployment as the end of the process. In fact where you are today, and where you will be tomorrow, can greatly impact both the selection and deployment of a technology. Having a clear enterprise architecture or technology road map greatly influences how you use and deploy technology going forward. The following document is based on the original AAEP process and so focuses on the concepts and deliverables of a Lotus Domino migration, but all of the concepts and process components are applicable to any migration.

Why Migrate?

With any migration, there is a tipping point or starting place that begins the analysis and consideration of migration from one technology to another. This is the why of the migration, that driving reason for moving. That single reason might, in fact, be many reasons and, often, is one of the following:

  • Cost reduction—Lowering the TCO/ROI of the current solution with a new solution.
  • Capability enhancement—Being able to do something with new technology that you cannot do (or it is much more expensive/difficult) with the older technology.
  • Paradigm shift—The new solution fits better with the long-term vision of the organization.
  • Merger/Acquisition—Your company is acquired by/acquires/merges with another organization running a different technology. During this process, the decision is made to deploy a different technology.
  • Partnership—Your organization now is partners with a new organization that sells a technology competitive with what you are using.

All of these push us to consider a migration.

Developing a Business Driver for Migration

Strong drivers lead to solid migrations. So, the first component that we will consider is the driver for the migration itself. This initial work stream, the driver, will determine the overall direction, strategy, and at times the success of the migration. The reality is a strong business driver for a migration will allow the organization to spend the money required to be successful in the migration. MMPP starts with the creation of the business case. Developing this business case is critical to the success of the migration. Because MMPP is a process and not a framework, you can leverage any business case or model your organization prefers to use. The capture of data for and development of a business case for an organization can be interlaced with the MMPP process.

With the overall collection of data for the business case in process for MMPP, we can also begin capturing the initial sets of technical information. The technical information is critical for the initial risk assessment of the migration. While the information will be used for development of the what and how of the overall migration, its initial use is for the creation of the risk document.

Determining the how and the what are rather straightforward processes. We offer guidance called the Microsoft Migration Planning Process (MMPP) to guide you in determining them for your migration. The first steps of MMPP are detailed in the following section.

Building the Business Case

Determine to whom you will need to talk from the business, and set up initial interviews. These interviews will help flesh out the why of the migration. The business process and stakeholders will guide you towards those areas that are critical to the organization:

  • Key management
  • Key stakeholders
  • Key process owners

Determine to whom you will need to talk from IT, and set up initial interviews. The IT professionals will help you determine both the how of the migration and will also give you a solid picture of the "as is" state of the infrastructure today. That will include people from the following groups:

  • Architecture team
  • IT management
  • IT operations
  • IT administration
  • IT development

Determine to whom from the end-user community you will be talking, and set up initial interviews. These professionals might have little information to help you with the what, why, and how of the migration. But, if you migrate to a new technology that the end users cannot use or learn quickly, you add to the overall cost of your solution. Users will include the following:

  • Power users
  • Executive assistants
  • End users

Finally, you will be running various automated tools as part of the MMPP. Some of the tools might require third-party participation or rights and privileges on the network. Make sure that all tools have been evaluated prior to using them in production, and request all rights and privileges that are required prior to starting. These tools include:

  • A tool that will discover the functionality that is enabled by the old infrastructure and classify that for review prior to migration.
  • A tool that will gather usage data around the infrastructure. If the customer does not have specific usage tools or even scenarios, you can capture this data by using server logging.

Where Am I in the Process?

You are in Phase I of MMPP:

  • Develop business case.
  • Develop list of applications to be considered for migration.
  • Develop list of data to be considered for migration.
  • Develop interview list and topics.
  • If available, run automated discovery tools.
  • Surveys for current-state infrastructure.
  • Surveys for current-state development methods.
  • Architectural information review.

How Do We Migrate?

After you have established the why of your assessment, you also must consider the broader questions of what and how. How describes both the mapping of existing capabilities to a newer infrastructure and the process by which you will assess the current state and design the to-be state of your infrastructure.

The how of a migration involves many things, not the least of which are the tools used to move the information from the old system to the new system. The other side of how represents the view of the migration taken by the organization. How will we accomplish the following?

  • Move only information.
  • Move both information and functionality.
  • Move only functionality.
  • Consolidate information.
  • Consolidate functionality.

A tenet of migrations is "the more you move the more it costs." While that simple statement applies to all migrations, there are also other factors that must be weighed in approaching both a functionality and information migration. Many organizations embark down this path only to realize that technology and information have life cycles. As part of the how of the migration, we will develop two things:

  • Organizational information life cycle
  • Move information.
  • Consolidate information.
  • Organizational technology life cycle
  • Move functionality.
  • Consolidate functionality.

How the organization deals with these two areas is critical. Cutting-edge knowledge-management solutions will not work in an organization that keeps its information for 100 years. Likewise, if your solution requires the newest mobile technology, and your organization sits in the lagging curve of adoption, you put your overall migration solution at risk.

More information on building an information life cycle can be found in the article "Information Life Cycle," in the MSDN Library.

With this, we break how into two pieces: the first being the tools and the tools-selection process; and the second being the overall direction of the migration, as it relates to specific components of the current-state solution. Table 1 shows a migration sheet, detailing the life cycle matched to both the decision and the migration tool to be used.

Table 1. Migration planning

Function or dataInformation life cycleTechnology life cycleMigration toolDecision
HR—New employee systemPerpetual (data must be kept for more than five years). Moving data to SQL Server for archive. Moving functionality to SAP.Migrate.
New computer (end user)Any managed data must be migrated if within life cycle for that information.Two-year replacement life cycleAutomated requisition process based on embedding date of PC in end-user schema attributes. LDAP query determines who is near end of life. Web site is created for bulk orders to reduce cost.Rip and replace.
Archive data of customersData taken offline after five years. Keep solution in place until the end of the current data life cycle. Build a new solution to replace this starting year two.Year one: Leave in place.

Year two: Replace functionality with a new solution.

As we document the how of the migration in Phase I and Phase II, it is important to remember that any data that is being considered should have the decision criteria evaluated against the information life cycle that applies to that particular data/functionality. There is nothing more costly in a migration than spending five years migrating data that expires two weeks after you finish the migration.

What Do We Migrate?

Beyond the how lies the actual what of our migration. The what is a mapping process by which we determine what is critical for the business to move forward. Moving all of an organization's data might not be required; or, if there are legal or regulatory issues, it might be. However, the what, which is the critical business functionality, has to be moved. Moving data without functionality will result in cost (lost productivity).

This mapping simply represents the deployed infrastructure in two buckets: the first bucket being functionality, and the second bucket being data. While, previously, we were determining the overall direction and the tools- and process-based how of the migration, this what details the actual components that will be deployed.

We can map this into a table, to make the concept easier to understand.

Table 2. Migration considerations

Data typeMigrate?Consolidate?Discard?Alter/Edit?
Functionality typeMigrate?Consolidate?Discard?Alter/Edit?

In the how process, we looked at the data as it related to life cycles, to determine both if it was eventually going to be required or if it fit outside the standard migration pattern of the organization. Now, we look at the other questions relative more to what than how. Those ask, "What do we do with the data/functionality now?" We begin a series of decisions (from data that we gather in Phase I and Phase II) during Phase III.

Minimizing Data Loss

As an organization considers the concept of migration, there is a significant fear of data loss during the migration. This "risk" forces many companies to rethink a migration, regardless of the overall cost benefits and the eventual process improvements. This is why a critical component of the MMPP process is the classification and structuring of the data within the organization during the planning process.

Minimizing Impact on the Business

MMPP considers the options carefully during a migration. The area of functionality mapping allows us to determine which business-critical functionality will be migrated and when that functionality will be moved. This allows the risk team to build-out an acceptable back-out and structured migration plan to minimize the impact to the business. In the case of mission-critical functionality, that functionality can be built in parallel, so that users can be trained for any changes prior to the actual migration.

Example Migration: Planning a Lotus Domino Migration

To show MMPP in the wild, we have selected a Lotus Domino assessment to demonstrate the four phases in-depth as it would relate to a specific migration.

Figure 1 is, essentially, a functionality review of the customer's deployed applications and capabilities. This tree maps the overall process in relationship to the various conversations that occur during the assessment. Each conversation represents a capability of the customer's business and results in different components of the overall application-assessment process.

There are three things that we want to consider critical in a migration from Domino functionality to Microsoft functionality. These three core areas are dependent upon each other, to a degree, but can also stand alone as business functionality:

  • Messaging and calendaring migration
  • Directory services and directory migration (data)
  • Application-migration process

Click here for larger image

Figure 1. Microsoft Migration Planning Process (MMPP)

As we see in this initial process flow for applications, there are four core conversations that we will have with the customer. These conversations map to the key stakeholders in a notes migration, and they include the following:

  • Architects
  • Technical (migration and development)
  • Business owners
  • Others:
  • Deployment specialists
  • IT management
  • IT technical staff
  • End users
  • Business-process owners

These conversations have different goals and objectives within the conversations, but all four drive the final assessment results. There are also separate work streams that spawn from this. These separate work streams include the directory-services migration and the coexistence of the mail systems. Additionally, the application-assessment (MMPP) work stream also spawns from this. The four steps of the MMPP are detailed later in this document.

Click here for larger image

Figure 2. MMPP with directory and messaging process

Communication Process Flow

Please note that any communication flow does not represent a prescriptive view of the communication, but is instead guidance around the various potential communication points within an assessment. These additional work streams would be spawned based on the conversations consultants had with the stakeholders. Each of the stakeholders would engage at different levels within the process, with different expected results.

Business Owners

Click here for larger image

Figure 3. Business-owner conversations

The business-owner conversations would include several key components for building the total cost of operations/return on investment (TCO/ROI) business case for migration. Additionally, the business interviews would work towards defining the functionality (or capabilities) the business is looking for/needing in the near and long term. The business interviews would occur early in the assessment phase and would end with a discussion of the mission-critical notes applications. This discussion would focus on the four core "areas" for migration consideration:

  1. Applications with data
  2. Applications with data and process
  3. Applications built with a three-tier model (data, process, and presentation)
  4. Applications built in an n-tier model


Click here for larger image

Figure 4. Technical conversations

Within this conversation the two technical camps (administrators and developers) move through the components of the assessment based on the agile framework Microsoft Solutions Framework V4. This iterative process starts in the plan phase, in which the team would work on completing core components of the technical questionnaires. Key milestones would be developer interviews and migration planning.

  • Network topology:
  • Net available bandwidth
  • Current network upgrade plans
  • Name services
  • Directory:
  • Authentication
  • Authorization
  • Identity management
  • User life cycle
  • Operations
  • Messaging:
  • Antivirus
  • Antispam
  • Storage
  • SMTP routing
  • Messaging delivery
  • Message retention
  • Operations
  • Applications:
  • Development process
  • Deployment process
  • Scaling/sizing
  • Operations
  • Operations process and procedures


Click here for larger image

Figure 5. Architect conversations

A core component of these conversations will be to ascertain what the customer has documented about their current environment:

  • Network design
  • Directory design
  • Messaging topology
  • Application topology
  • Development methodology and process
  • Operations process

Technical View of a Lotus Domino Migration Assessment

Click here for larger image

Figure 6. High-level technical view

In this view, we see the various work streams that are spawned off to produce the application migration and the directory/messaging migration. These two streams result in the final customer presentation of the migration options for applications and directory/mail. The grouping of functionality and additional application reduction are covered later in this series (MMPP II, Solution Mapping). In accessing a Lotus Domino application environment, we used the Microsoft Application Analyzer for Lotus Domino 2006 to capture automated information, although there are other applicable tools. This tool will provide information in the following buckets:

  • Applications that can be discarded (not leveraged in more than x days).
  • How applications fit into the broader Microsoft Lotus Domino Application Classification structure (often called the Quadrants).
  • Which applications include workflow and other mail-enabled functionality.

Beyond these conversations, you might have formal conversations with developers, deployment specialists, IT helpdesk, end users and others to complete the picture. Like a 360 degree review, this process helps present a holistic view of the infrastructure. At various times later in the process, you will revisit and often review these conversations.

Phase I of the MMPP: Current-State Assessment (Applied to Our Lotus Notes Migration Example)

As we consider the components for a migration this first phase is critical. Phase I is truly where we establish both the current state both of technology and the organization as a whole. This phase is about information-gathering, but also it's about accessing the organization both from technology- and information-process levels.

From surveys, automated tools, and interviews, we will build the picture of the current-state environment. We will also access the information processes, as well as the organizations tolerance for new technologies.

This initial phase of MMPP is designed to gather data around the current-state infrastructure deployed within the organization. This step would include the use of automated tools, surveys, and live interviews with various roles within the organization. As we are mapping our framework and process to a live migration type, we are moving forward as though this were a migration from Lotus Domino to various other technologies. The reason this was selected has to do with the overall breadth of the migration and the complete replacement of many core functions. Other migrations might be smaller in scope, but you can easily pick out the valid components from the broader migration and apply them to the smaller one.

Establishing the As-Is State

The goal of this initial phase is to perform a cursory review of the Lotus Notes/Domino infrastructure, business needs, and applications to identify those areas that need additional, in-depth analysis. In other words, this phase is aimed at achieving a high-level understanding of the current and future business requirements for collaboration. Tasks in this phase include:

  • Documenting the current Lotus Domino application infrastructure, including number, version, and location of Lotus Domino servers; replication topology; and backup and disaster recovery plans.
  • Identifying the applications that are unlikely candidates for migration, such as mail and administration applications.
  • Discovering the applications that can easily be migrated using Microsoft Application Transporter 2006 for Lotus Domino.
  • Grouping together applications that share a common design, so that analysis and recommendations can be performed a single time for these applications.
  • Listing replica copies of applications, so that analysis is performed only once for each unique application.
  • Identifying the applications that require additional analysis.
  • Performing a risk assessment of the migration for the organization.
  • Performing a formal assessment of existing deployed solutions in the organization that can be leveraged later for migration.
  • Determining any third-party companies (migration-tool vendors) that have existing relationships. If none, research the tools that are available for migration, and consider what the options will be for each.

What Am I Trying to Do?

In first steps of this phase you are trying to:

  • Establish a current-state picture of the various technologies deployed.
  • Establish a view of the development environment and process.
  • Establish an end user's views of the deployed solution.
  • Establish a view of the business processes enabled by technology
  • Build an inventory of the applications in the environment, where they are running, and which ones are mission-critical.

What Are My Expected Inputs?

One of the most important sources for information is the survey. You will use the following surveys to accomplish your goals:

  • Technology surveys:
  • What is deployed?
  • How does it work?
  • Are there known or open issues?
  • Where do you see the technology/capabilities of the organization in five years?
  • Where do you see the technology/capabilities of the organization in two years?
  • Business surveys:
    • How does your organization produce revenue? (What technologies support your revenue stream? What manual tasks are still completed?)
  • Where do you see the technology/capabilities of the organization in five years?
  • Where do you see the technology/capabilities of the organization in two years?
  • How are "business" requirements gathered?
  • End-user surveys:
  • What works well today?
  • What must be improved?
  • What has changed (process) since the original solution was deployed?
  • How do you get support for "XZY" functionality?
  • What applications do you use in your day to day job functions?
  • What applications do you use monthly?
  • What applications do you use quarterly?
  • What applications do you use annually?
  • Interviews are another valuable source of data. You will interview the following people to find out relevant business information, such as how projects get funded:
  • Developers
  • Administrators
  • Business owners
  • End users, if possible
  • Another crucial data-gathering technique is through automated tools. These will help you determine relevant current-state information, such as:
  • What is deployed?
  • Where is it deployed?
  • Who uses it today?
    • Then, you will match applications surveyed by automated tools and which are mission-critical—and do the two lists match.
      • Automated data-gathering through:
    • Server performance.
    • Network performance.
    • Application performance.
    • Application usage.
      • Determine need for other automated tools:
    • Missing information
    • Additional information

Table 3. Actions for each input

InputAction to be taken
Survey dataCompile into single source document and remove all duplicated information.
Interview dataCompile into single source document and remove all duplications.
Automated toolsCollect classification information, and compare to information gathered in the survey and interview processes.
Architectural documentation (other documentation)Review and ensure that missing/required documentation that is not available is noted.

Review for existing documents to understand the solution as deployed.

Determine need for other automated toolsDocument requirements (missing information or additional information) required from third-party tools.

Relevant Infrastructure Information

Gathering data is one thing, organizing it is another. You will have to determine a way to structure all of the information you are collecting.

  • What is the naming structure?
  • What technologies are considered for new projects?
  • Data storage?
  • Network and security access?
  • Information creation and storage?
  • Information management?
  • What is the network topology?
  • Maximum available bandwidth?
  • When is the network at its maximum usage?
  • When is the network at its minimum usage?

As you dive into the MMPP, a critical point is that you do not have to use every step of this process to be successful. Instead, the goal of the MMPP is to help you work to ensure that the right capacity exists in your infrastructure, and that the right functionality gets migrated.

Click here for larger image

Figure 7. Application and functionality funnel

What Will My Outputs Be?

  • From this process, you will have a reduced list of applications to be considered for migration. These will include:
    • Classification of applications by quadrant type.
    • Classification of applications by usage.
    • Creation of a master list of all applications.
  • List of applications that can be removed (discard)
  • List of applications that can be consolidated (replicas)
  • List of applications that can be consolidated (same functionality)
    • Documentation of interviews and questionnaires.
    • Additional automated-tool data.

The MMPP process and timeline depend upon who is involved. Surveys can be sent at any point during the initial or beginning process. The survey information can be collected by the sales team or by the technical team that is performing the assessment.

What the Sales Team/Stakeholder Team Must Do

The sales team must complete several core tasks in the assessment process:

  • Schedule the interviews for the technical team, so that there is no wasted time onsite.
  • Determine the expected end state deliverable the customer is expecting.

What the Technical-Assessment Team Must Do

  • Tailor the initial surveys to the specific customer (industry-specific).
  • Develop initial questions for interviews.
  • Set documentation standards.
  • Initial conversations:
  • Set up interviews.
  • Retrieve survey data (large customer).
  • Develop initial criteria around application use.
  • Get Notes ID to run all automated tools (read-only access).
  • Set up time (potentially off-hours) to run various tools.

Documentation You Will Need

While this is not a comprehensive list, is does point you in the right direction as to the various types of documentation for which you should be looking. Few, if any, organizations will have all of these documents available, but all will have some.

  • Security architecture:
  • Application security
  • Development security
  • End-user security
  • Regulatory requirements
  • Remote-access architecture
  • Communication plans used in previous projects
  • Logistics documentation:
  • Hardware-acquisition process
  • Timing and other hardware guidelines
  • Standards guides for the organization
  • Project plans:
  • Previous design projects
  • Previous migration projects
  • Previous deployment projects
  • Risk documents from previous projects
  • System-policy documents:
  • Acceptable use documentation
  • Mailbox and other retention rules
  • Operations guides for solutions
  • Project-management standards and guides
  • Legal and regulatory guidance documents
  • List of deployed third-party applications:
  • Status of applications today (version: deployed, and so forth)
  • Upgrade and additional plans for any applications already deployed
  • Development standards:
  • Development process
  • Code libraries
  • Coding requirements
  • WAN capacity and configuration
  • Any architectural documents:
  • Workflow design
  • Mail routing and design
  • Domino Server design and standards
  • Mobility design
  • DNS and other namespace design
  • Directory structure for users and groups

Where Am I in the Process?

  • Phase I is complete.
  • This is the baseline or beginning of Phase II.


An old proverb begins, "The journey of a thousand steps begins with the first." As it is with migrations! This first phase of the migration gets to a clear understanding of the why we would migrate. Now, we begin the technical process of ensuring that we have the right components to improve the business by migrating.

The next component of this series is "Microsoft Migration Planning Process, Part 2: Plan, Build, and Succeed," which kicks off Phase II of the MMPP process.