Project Planning for System Migrations

Vincent Goldsmith, PMP, CSM

Agenda

Introduction

Migration Goals

Drivers

Portfolio Analysis

Requirement Recovery

Business Architecture

Target Architecture

System Design

Migration Paths

Implementation

Risk Mitigation

Stakeholder Buy-in

Conclusion

Introduction

• 25 years project management experience

• 15 years in IT

• Senior Project Manager with GDIT

• Currently assigned to a CMS Pay-for-

Performance Healthcare Project

(representative current and past clients and

associations shown)

PMBOK Alignment

Initiating Planning ExecutingMonitoring

and Controlling

Closing

Integration

Scope

Time

Cost

Quality

Human Resource

Communications

Risk

Procurement

Stakeholder

What is System Migration?

It is the transferring of IT resources to a newer hardware infrastructure or software platform for the purpose of keeping up with current technologies and/or to gain better business value in the long run.

Why This Is Important

• A lot of IT development is improving an existing system, usually resulting in the adoption of new software or hardware technologies (e.g. migration).

• Examples of IT Migrations:– Cloud Migrations (SaaS, IaaS, PaaS, etc.)

– Service Oriented Architecture (SOA)

– Open Source to Custom Code (or back again)

– Operating Systems

– Data migrations

Why This Is Important• IT Migrations are complicated because of the

following:– Differences in source and target architectures– Known and unknown dependencies– Undocumented requirements– Impact to business operations– Applications are rarely portable across different

technologies– Developers and/or users are not trained in new

technologies– Non-routine processes and procedures

(reengineering doesn’t happen every day)

Project planning is important because IT projects are hard enough without these complications….

70% of organizations have suffered at least one project failure in the prior 12 months – KPMG (2010)

60% of projects failed to meet schedule, budget and quality goals – IBM (2008)

37% of business process change projects fail to deliver benefits –Logica (2008)

38% of data migration projects fail – Computer Business Review (2013)

GAO: $10 billion worth of current federal IT contracts could fail –Washington Post (2014)

17 percent of large IT projects go so badly that they can threaten the very existence of the company – McKinsey & Company (2012)

Why This Is ImportantFrom people who have studied this stuff…

Excuses – Excuses - Excuses

• “If managing technology pays your mortgage, you usually explain away those failures by pointing to your gray world: gray requirements, gray resources, gray planning, gray risks. The only vibrant color in your life is the brilliant hue of overly optimistic project scheduling.”

– “Why Tech Projects Fails, 5 Unspoken Reasons”, Information Week, April 2013

We Do It To Ourselves

• The biggest barriers to success are people factors IBM (2008)

– Changing mindsets and attitudes – 58%.

– Corporate culture – 49%.

– Lack of senior management support – 32%

– Underestimation of complexity listed as a factor in 35% of projects

• “Fuzzy business objectives, out-of-sync stakeholders, and excessive rework” mean that 75% of project participants lack confidence that their projects will succeed from the start of the project (Geneca 2011).

We Can Do Better

Planning Goals

Goals for a Migration Project

• Successful migration of applications or data to new software and hardware technologies.

• Least amount of business disruption or risk to business operations.

• Predictable timeline for when functionality will be migrated.

• Adoption and use of migrated products and services.

Outputs of Migration Planning

Scope• What applications are in scope for migration• System boundaries

Schedule• Timeline for implementation• Date of completion

Project Management Plan• Updates to Quality Management Plan, Risk

Management Plan, Communications Plan, etc.

Scope, Schedule and Project Management Plan

MIG

RA

TIO

N C

OM

PLE

TE

Migration Planning Framework

Target Architecture

Portfolio Analysis

Requirement Recovery

Business Architecture

Implementation

Migration Path

Establish Baseline

RET

AIN

REP

LAC

E

REF

AC

TOR

RET

IRE

REV

ISE

REB

UIL

D

REH

OST

System Design

Identify Drivers

Road Map

STAKEHOLDER BUY-IN

RISK MITIGATION

QUALITY ASSURANCE

Business & Technical Drivers

78% of respondents reported that the “Business is usually, or always, out of sync with project requirements”

– Geneca (2011)

Main Drivers for Migration

• The current system no longer performs as expected or needed.

• A faster or better performing technology becomes available.

• The old system becomes deprecated and support is difficult or no longer available for it.

• The company is taking a change in direction.

• Cost of development or support.

Other Considerations

• Migration is sometimes driven by IT management and not business management, but that doesn’t mean the business needs shouldn’t be addressed.

• Analyzing drivers may uncover business reasons that will end-up driving your strategy or schedule:– security concerns, capacity or performance concerns, data

quality concerns, compliance reasons, new business initiatives that can’t be accomplished in the legacy architecture

• Reasons to migrate can be both business or technical in nature.

Perceived Benefits

Perceived Benefit (example) Business Technical

Rapid Time to Market X X

Deliver New Capabilities X X

Modernize Applications X

Accommodate Scalability X

Free-up Data Space X

Operational Efficiencies X

Provide Access to More Users X

Improve Performance X X

Better Data X

Improve Security X X

Leverage existing investments X X

Other Considerations

• Fully understanding the business drivers allows you do the following:

– Establish a timeline acceptable to the business that accommodates their schedules and deadlines

– Prioritize functionality or applications that need to be migrated (scope)

– Form a plan for the migration that minimizes business risk while maximizing business value

Drivers are not Static

• They need to be revisited throughout the migration process to determine if they are still relevant or if benefits are being realized.

• All the analysis and decisions that follow should be assessed as compared to the drivers.

Legacy System Analysis

Legacy Systems

They represent:

• Huge Investment

• Baseline for Future Functionality

Portfolio Analysis

All applications are reviewed by representatives of the business and technical teams and judged according to the following:

• Functional Value• Technical Value

Qualitative judgments are given quantitative values and a weighted score is calculated for each application.

Applications are reviewed and a decision is made on the prospects of the applications.

Return-on-Investment (ROI) should be calculated and evaluated against the cost of migration.

Functional Analysis

Evaluate Legacy Systems to see if they meet the needs of the business (examples):

• Business Need/Functionality (don’t migrate what you can eliminate)

• Business efficiency or workflow automation

• Performance

• Usability

• Strategic Fit

Technical Analysis

Evaluate Legacy Systems to see if they meet the needs of the people supporting the technology (examples):

• Technical Maturity• Technical Debt• Data Dependencies• Architecture• Portability• Reliability• Interoperability• Cost of development and support

Legacy Data Issues

Evaluate Legacy Systems for data quality issues (examples):

• Bad data in legacy system

• Duplicate data in legacy system

• Unknown or unenforced archiving policies

• Upstream data dependencies or third-party data needs

Possible Decision Outcomes

Decision Definition

Retain No changes made to application

Replace Discard existing application and replace with COTS

Refactor Making application or configuration changes to upgradeapplication without changing functionality

Retire The functionality of the application is no longer needed by the business.

Revise Extending existing legacy application functionality to accommodate business needs

Rebuild Completely rebuilding the application with a brand new architecture

Rehost Deploy applications to a different hardware environment and/or changing the infrastructure

Legacy Portfolio Analysis

Application Portfolio Decision Analysis

FUN

CTI

ON

AL

VA

LUE

TECHNICAL VALUE

RETAIN

REBUILD

REFACTOR

RETIREREVISE

REPLACE

REHOST

Requirement Recovery

Undocumented Requirements

• Incomplete requirement documentation is an issue in legacy systems migrations.

• Unclear requirements are one of the contributing factors to IT project failures, so it is important to document all of the business requirements.

• Business requirements should be further broken down into functional and non-functional requirements and/or technical and functional specifications.

• Legacy requirements may change depending on the outcome of the Portfolio Analysis.

Sources of Requirements

• Re-elicit requirements

• Reverse engineer existing applications by reviewing code

• Review Business Architecture and BPMNs

• Review training materials, user guides, release notes for info

• Review test cases if available

• Analyze inputs and outputs

Requirement Management Still Applies

• Have a requirements management plan

• Requirements should describe functionality and outcomes, not technical implementation

• Requirements and associated documents should be kept under change management

• Maintain clear traceability of requirements

• Strive for enterprise-wide requirements as opposed to application-specific requirements

More Info

There is an abundance of scholarly papers on how to elicit, derive, and represent user requirements, including:

• Semantic Analysis

• Analyst Constrained Language (ACL)

• Norm Analysis

• Etc.

Business Architecture

Business Architecture

• Business architecture defines how the enterprise needs to operate in order to achieve business objectives.

• It is the first architecture activity that takes place.• The existing business architecture is usually

defined within the legacy system.• It should be verified, analyzed, and updated as

necessary.• Business processes not being brought forward

into the new system should be removed.

TOGAF Business Architecture Steps(The Open Group Architecture Framework)

1. Select Reference Models, Viewpoints, and Tools

2. Develop Baseline Business Architecture Description

3. Develop Target Business Architecture Description

4. Perform Gap Analysis5. Define Candidate Roadmap

Components6. Resolve Impacts Across the

Architecture Landscape7. Conduct Formal Stakeholder Review8. Finalize the Business Architecture9. Create Architecture Definition

Document

Other Considerations

• Value engineering and possible cost-cutting should be made part of the process.

• Validate and redefine business rules.

• Identify cross-process dependencies.

• Identify inputs & outputs of the system boundaries within the business architecture.

• Adhere to standards and governance.

Outputs of Defining the Business Architecture

The following diagrams should be considered as possible outputs of the Business Architecture process (more from Togaf-modeling.org):• Business Footprint diagram• Business Service/Information diagram• Functional Decomposition diagram• Goal/Objective/Service diagram• Use-case diagram• Organization Decomposition diagram• Process Flow diagram• Events diagram

Business Footprint DiagramProvides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified.

Source: togaf-modeling.org

Functional Decomposition Diagram

Shows on a single page the capabilities of an organization that are relevant to the consideration of an architecture.

Source: togaf-modeling.org

TargetArchitecture

Target Architecture

• It serves as the overall framework for the solution architecture.

• It is the formal documentation of the desired future vision -defining and validating future requirements and the optimization of opportunities.

Additionally…• It is the high level plan for the relationship between

business and application systems.• It defines the relationship between business and

information.• It describes the relationship between business and

technologies.

Describing the Target Architecture

• Data Standards:– Coding and values for data– Structures and formats for data– Ownership of data– Restrictions on access

• Applications Standards:– Standard/shared applications and services that support specific

business functions– Application communication, interfaces and interoperation– Access, presentation, and style

• Technology Standards;– Hardware product standards– Software product standards– Software development standards

Creating the Target Architecture(example process)

Source: A Practical Guide to Federal Enterprise Architecture

System Design

System Design

System design is the complete set of documents necessary to implement the applications.

Documents can include:

• Data Models

• Interface Control Documents

• Configuration Documents

• System Implementation Plans

System Design• Trace technical solutions at the component level to

requirements.

• Design the system so it can be implemented iteratively to accommodate your migration path.

• There might not be a one-to-one relationship between new components and legacy components.

• Review performance and security issues that may arise between new and existing applications and architectures.

• Enforce standards and change control with new system designs.

System Design

• Design for common shared elements when possible.

• Have a preferred mechanism for common capabilities (build these first):– Authorization

– Communication/email

– Synchronization

– Error handling

– Event logging, etc.

Design for Incremental Migration

• Changes in protocols or database formats should accommodate existing data, applications and devices in order to be backward compatible.

• Wrapping existing applications with new APIs can facilitate incremental migration while allowing for backward compatibility.

Migration Paths

Transition Architecture: “In Flight”

• When choosing a migration path there are three basic strategies:– a completely new implementation.– a radical “all or nothing” change (i.e., switch on, switch

off).– a phased approach to introduce new capabilities with

parallel legacy and migration systems running simultaneously.

• Of these, a phased approach is the lowest risk method and allows for easy and quick wins to prove the migration will work.

“As Is” System

UI

Business Logic

Data

UI

Business Logic

Data

UI

Business Logic

Data

UI

Business Logic

Data

UI Domain

BusinessDomain(s)

Data

“To Be” System

UI

Business Logic

Data

Business Logic

Business Logic

Business Logic

UI Domain

BusinessDomain(s)

Data Cloud Big Data Appliance

Iterative System“In Flight” Option: Migrate by App

UI

Business Logic

Data

UI

Business Logic

Data

UI

Business Logic

UI

Business Logic

Data

UI Domain

BusinessDomain(s)

Data Cloud

Iterative System“In Flight” Option: Migrate UI

Business Logic

Data

Business Logic

Data

Business Logic

Data

Business Logic

Data

UI Domain

BusinessDomain(s)

Data

UI

BusinessDomain(s)

Iterative System“In Flight” Option: Migrate by Domain

UI

Business Logic

Data

UI

Business Logic

Data

UI

Business Logic

Data

UI

Business Logic

Data

UI Domain

Data

Iterative System“In Flight” Option: Data Migration

UI

Business Logic

Data

UI

Business Logic

UI

Business Logic

UI

Business Logic

UI Domain

BusinessDomain(s)

Data Cloud Big Data Appliance

“To Be” System

UI

Business Logic

Data

Business Logic

Business Logic

Business Logic

UI Domain

BusinessDomain(s)

Data Cloud Big Data Appliance

Implementation

Implementation

• Identify enterprise architecture and implementation priorities for development teams.

• Identify deployment issues and determine corrective actions.

• Pay attention to the scope of migration efforts and iterative development schedule.

• Extract, clean, transform and de-duplicate the data.

• If necessary prepare scripts for data, server or database migrations.

Implementation Teams

• Current technical and or business SMEs have detailed knowledge critical to not just the ongoing O&M of the system, but they are also critical to the migration effort.

• New technical SMEs may be needed for the development or implementation of new systems.

• Implementation Teams made up of a mix of current and new technical and business resources maximize potential for success.

Implementation Team Example

Application UI Developer Service Developer

Database Developer

FunctionalSME

Component 1 LegacyDeveloper

MigrationDeveloper

Legacy Developer

Legacy SME

Component 2 Migration Developer

Legacy Developer

Migration Developer

Legacy SME

Component 3 Migration Developer

Migration Developer

MigrationDeveloper

Legacy SME

Training

• Training for the existing technical staff is needed so that new habits and design practices will be used when working with the new architecture.

Risk Mitigation

Risk Mitigation

• Parallel environments (ongoing legacy operations and migration implementation) should be leveraged.

• Establish and maintain configuration management control of the legacy system even while migrating.

• There should be a separate and distinct reengineering process that doesn’t interfere with the ongoing operations of the legacy system.

• When outside services are needed, carefully define and monitor their roles.

Risk Mitigation

• Restrict migrations to off-hours when usage is low and won't interfere with your ongoing operations.

• Maintain a clear audit trail of all data migration activitity (who, what and when).

• Validate and test the data-migration process.

• Don’t plan to go live in one big upload at the end – work incrementally.

• Training – training – training.

D Quality

Quality Assurance

• Parallel environments will allow you to compare migrated test results to baseline.

• UAT testing should be done on migrated components (training will be needed).

• Maintain traceability of test cases back to requirements.

Data Quality Assurance

• Back-end testing is critical when migrating incrementally because you want to be able to test components as they are developed.

• Testing of the migration run (ETL) should be done to make sure all three stages are functioning correctly.

• Test the migrated data to ensure it's accurate and in the expected format.

• If scripts are being used to migrate data, servers, etc. – the scripts should be tested thoroughly as well.

User and Developer Buy-in

Stakeholder Buy-In

Stakeholder Buy-In

• “75% of project participants lack confidence that their projects will succeed, even from the start of the project”

Stakeholder Buy-In

• Development team and User buy-in is critical to success (many IT implementations fail due to insufficient adoption of new technology).

• Provide adequate training and communication in both the technical content and the reason for the change.

Stakeholder Buy-In

• Get input from legacy SMEs, Technical Staff and Usersvery early in the process – and ask them for their opinions.

• Create a team-oriented reengineering plan.• Have a subset of users who are involved throughout

the migration process.• Project and team onboarding should include an

overview of the migration strategy.• Demonstrate products early and often.• Overcommunicate progress and success.• Celebrate wins early and often.

Sponsorship

• The migration project should have a senior manager sponsor.

• Management needs to be committed for the long haul.

• Management edicts should not override technical realities.

Conclusion

Review• Work early and often to achieve and maintain

stakeholder buy-in (users and technical staff) through training and communication.

• Continue to revisit business and technical drivers to make sure you’re delivering value.

• Develop a comprehensive strategy with achievable and measurable milestones for the project.

• Deliver incremental migration.

Scope, Schedule and Project Management Plan

MIG

RA

TIO

N C

OM

PLE

TE

Migration Planning Framework

Target Architecture

Portfolio Analysis

Requirement Recovery

Business Architecture

Implementation

Migration Path

Establish Baseline

RET

AIN

REP

LAC

E

REF

AC

TOR

RET

IRE

REV

ISE

REB

UIL

D

REH

OST

System Design

Identify Drivers

Road Map

STAKEHOLDER BUY-IN

RISK MITIGATION

QUALITY ASSURANCE

And Remember

…We Can Do Better

More Information• Five Options for Migrating Applications to the Cloud: Rehost, Refactor,

Revise, Rebuild or Replace (.pdf) – Gartner

• A Practical Guide to Federal Enterprise Architecture (GAO)

• The Object Management Group (OMG)

• The Open Group Architectural Framework (TOGAF)

• Information Technology Infrastructure Library (ITIL)

• Software Engineering Institute (SEI)

• Project Management Institute (PMI)

• AgileModeling.com (for modeling and documentation)

• Togaf-modeling.org (for modeling and documentation)

The End

Questions

linkedin.com/in/VincentGoldsmith

Vincent Goldsmith

VinnyGoldsmith@gmail.com

301-452-7906