1. Project Planning for
System Migrations
Vincent Goldsmith, PMP, CSM

2. Agenda
 Introduction
 Migration Goals
 Drivers
 Portfolio Analysis
 Requirement Recovery
 Business Architecture
 Target Architecture
 System Design
 Migration Paths
 Implementation
 Risk Mitigation
 Stakeholder Buy-in
 Conclusion

3. 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)

4. PMBOK Alignment
Initiating Planning Executing
Monitoring
and
Controlling
Closing
Integration
Scope
Time
Cost
Quality
Human Resource
Communications
Risk
Procurement
Stakeholder

5. 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.

6. 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

7. 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….

8. 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 Important
From people who have studied this stuff…

9. 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

10. 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).

11. We Can Do
Better

12. Planning
Goals

13. 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.

14. 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.

15. Scope, Schedule and Project Management Plan
MIGRATIONCOMPLETE
Migration Planning Framework
Target Architecture
Portfolio Analysis
Requirement
Recovery
Business Architecture
Implementation
Migration Path
Establish Baseline
RETAIN
REPLACE
REFACTOR
RETIRE
REVISE
REBUILD
REHOST
System Design
Identify Drivers
Road Map
STAKEHOLDER BUY-IN
RISK MITIGATION
QUALITY ASSURANCE

16. Business &
Technical
Drivers

17. 78% of respondents reported that
the “Business is usually, or always,
out of sync with project
requirements”
– Geneca (2011)

18. 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.

19. 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.

20. 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

21. 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

22. 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.

23. Legacy System
Analysis

24. Legacy Systems
They represent:
• Huge Investment
• Baseline for Future Functionality

25. 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.

26. 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

27. 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

28. 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

29. 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 upgrade
application 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

30. Legacy Portfolio Analysis
Application Portfolio Decision Analysis
FUNCTIONALVALUE
TECHNICAL VALUE
RETAIN
REBUILD
REFACTOR
RETIRE
REVISE
REPLACE
REHOST

31. Requirement
Recovery

32. 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.

33. 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

34. 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

35. 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.

36. Business
Architecture

37. 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.

38. 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 Analysis
5. Define Candidate Roadmap
Components
6. Resolve Impacts Across the
Architecture Landscape
7. Conduct Formal Stakeholder Review
8. Finalize the Business Architecture
9. Create Architecture Definition
Document

39. 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.

40. 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

41. Business Footprint Diagram
Provides 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

42. 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

43. Target
Architecture

44. 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.

45. 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

46. Creating the Target Architecture
(example process)
Source: A Practical Guide to Federal Enterprise Architecture

47. System
Design

48. 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

49. 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.

50. 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.

51. 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.

52. Migration
Paths

53. 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.

54. “As Is” System
UI
Business
Logic
Data
UI
Business
Logic
Data
UI
Business
Logic
Data
UI
Business
Logic
Data
UI Domain
Business
Domain(s)
Data

55. “To Be” System
UI
Business
Logic
Data
Business
Logic
Business
Logic
Business
Logic
UI Domain
Business
Domain(s)
Data Cloud Big Data
Appliance

56. 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
Business
Domain(s)
Data Cloud

57. Iterative System
“In Flight” Option: Migrate UI
Business
Logic
Data
Business
Logic
Data
Business
Logic
Data
Business
Logic
Data
UI Domain
Business
Domain(s)
Data
UI

58. Business
Domain(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

59. Iterative System
“In Flight” Option: Data Migration
UI
Business
Logic
Data
UI
Business
Logic
UI
Business
Logic
UI
Business
Logic
UI Domain
Business
Domain(s)
Data Cloud Big Data
Appliance

60. “To Be” System
UI
Business
Logic
Data
Business
Logic
Business
Logic
Business
Logic
UI Domain
Business
Domain(s)
Data Cloud Big Data
Appliance

61. Implementation

62. 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.

63. 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.

64. Implementation Team Example
Application UI Developer Service
Developer
Database
Developer
Functional
SME
Component 1 Legacy
Developer
Migration
Developer
Legacy
Developer
Legacy SME
Component 2 Migration
Developer
Legacy
Developer
Migration
Developer
Legacy SME
Component 3 Migration
Developer
Migration
Developer
Migration
Developer
Legacy SME

65. 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.

66. Risk
Mitigation

67. 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.

68. 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.

69. D Quality

70. 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.

71. 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.

72. User and Developer Buy-in
Stakeholder
Buy-In

73. Stakeholder Buy-In
• “75% of project participants
lack confidence that their
projects will succeed, even
from the start of the project”

74. 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.

75. Stakeholder Buy-In
• Get input from legacy SMEs, Technical Staff and Users
very 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.

76. 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.

77. Conclusion

78. 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.

79. Scope, Schedule and Project Management Plan
MIGRATIONCOMPLETE
Migration Planning Framework
Target Architecture
Portfolio Analysis
Requirement
Recovery
Business Architecture
Implementation
Migration Path
Establish Baseline
RETAIN
REPLACE
REFACTOR
RETIRE
REVISE
REBUILD
REHOST
System Design
Identify Drivers
Road Map
STAKEHOLDER BUY-IN
RISK MITIGATION
QUALITY ASSURANCE

80. And Remember
…We Can Do
Better

81. 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)

82. The End

83. Questions
linkedin.com/in/VincentGoldsmith
Vincent Goldsmith
VinnyGoldsmith@gmail.com
301-452-7906