1. Creating a safe, just and democratic society
RESTRICTED - MANAGEMENT
RESTRICTED - MANAGEMENT
FITS: Migrating Applications in relation to
Transitioning Application Services
Considerations: Application migration pitfalls, best
practices and lessons learned from other App
migration projects
Jay Jackson
29 November 2013

2. 2
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
Considerations: How much technical detail is known about applications?
• To take a view of how FITS Apps and App service transition happens (exclusively or together), it’s helpful to understand the App migration journey that each App will take, from
the point of view of the Application. When this is understood, wider discussion can take place in terms of the overall Apps service transition and App migrations.
• Before the migration story starts, it’s important to understand the quality of the App technical detail available for each Application.
• Regardless of the supplier count and supplier model, it’s important to understand is the CMDB a 100% valid and trusted source of information? Does this block or unblock
App migration planning? Significant delay to FITS Programme could impact if a discovery phase per App is required.
Application Owners
• Does IT Service Support/Delivery for the App rely on an Application Owner (Business App SME) to inform it about Application specifics? Does the App owner take business
responsibility for their Application? Is the App owner of sufficient authority level to signoff the migration change? Is this App profile CI information available in the CMDB or stored
anywhere else?
• Perhaps technical SME’s per application have long since left MoJ, with a knowledge gap about how the App technically functions?
• Does App specific knowledge exist per Application to enable a migration? Is App specific knowledge available to IT Service Management (support, delivery and FITS) today?
Suppliers
• Does a multi supplier model exist in terms of supporting the Application? i.e does more than 1 party share the totality of support for the App?
– It’s common for an Enterprise to split Apps delivery in the estate into separate services (dependent on each other) as follows:
• DC, WINS, DHCP, DNS, FAP – Active Directory/ Utility Server type of service
• Common Application Platform Service (this group might not know how many servers the App touches (the App owner may have this view?)
• 3rd
Party App Dev support service (internal support and development of the Application may or may not have this App topology)
• WAN/LAN MAN-Link Network / Firewall services (Does this supplier know:
– which protocols the App requires, and which TCP ports are in use?
– which ports are blocked?
– will these be enabled post migration?
– will the WAN/LAN configuration be duplicated and provisioned 100% accurately in the destination environment? How can this accurately and
confidently happen if the Network traffic is not fully understood?
• If a multi supplier model exists for Applications, then this may add complexity/gaps to Configuration Management detail that is required to plan and support a successful
migration.
• Perhaps the “in place profile of the Application” could sit across multi-suppliers, bringing multi CMDB’s into play (a common pitfall is the Network / Firewall space) external user
communities could be positioned remotely that might be invisible to FITS migration teams. If the App support team do not talk to the Network support team, how will the
complete and accurate user community be known?
• Perhaps Suppliers don’t want to share CMDB content with each other?

3. 3
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
Considerations: Discovery of an accurate and complete technical Application
profile
If the answer to considerations on the previous slide is that technical detail is missing per App, it might be important to complete
a discovery phase per App.
This adds complexity, additional time and additional cost to the programme, whilst important migration data is gathered per
application. This would be the invocation of a discovery phase….
What would a discovery phase look like and how would it unfold?
The following risk comes into play:
If the CMDB does not hold 100% accurate information about the application (enabling it’s profile to be used to support a
migration) then the migration may not be successful. This could cause rollback of the application adding delay and
cost to the FITS programme.
If FITS management are unwilling to signoff the above risk, then the following scenario could take place:
CMDB’s could become un-trusted sources of App info, so it might no longer be feasible to use the CMDB to view an application,
to understand it’s topology. If the above Amber risk is not accepted by management, it should be mitigated. Avoiding it entirely
may not be possible.
To mitigate the above risk, a discovery phase for App migrations might be required, to underpin accurate, complete and confident
migrations.

4. 4
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
Considerations: Teams involved in discovery
Who should complete a discovery phase? What would that team look like?
A central migration team could be used to complete the discovery phase for each application. This team could be outsourced to a
supplier or could be an internal MoJ department working closely with Application Business owners.
Central Migration Team Structure:
Project Manager to mange discovery artefacts per App, and facilitate discovery meetings (inc. RAID) with all relevant parties
Network / Firewall expert to carry out Network traffic sniffer trace reports per Server per Application (current MoJ Network
landscape knowledge might be advantageous ) to mitigate risk of technical unknowns
Technical architect to rationalise technical details provided per application
Server Engineers to physically and logically move/migrate App infrastructure
Central Migration Team Role:
The role of this team could be to profile each Application as part of a discovery phase. The output of this profiling could create a
migration design, along with valid technical application profile that is given to the Application SME for signoff, including key
RAID detail added by the above PM.
Application Business Owner or SME Team (usually one SME per App):
This could be a 3rd
party SME responsible for supporting the App
This could be an App owner (business level with authority to signoff the change)
The primary role of the App SME or Business App owner is to signoff technical discovery detail provided by the Central migration
team and validate it.

5. 5
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
Considerations: What could supplier driven migrations look like?
If a discovery phase is required, the below stages DP1 – DP10 could be used
If a discovery phase is not required, then the below stages DP3 to DP10 could be used
The below stages with quality achievements called out, could be used to generate a supplier App migration guidelines
document.

6. 6
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
Considerations: What would a Central Migration Team look like?

7. 7
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
Considerations: Migration strategies driven by CMDB quality
Regardless of the strategy to Migrate Apps and transition services , App migrations might need the capability to be rolled back following an unsuccessful
migration. This could be up-to 2 weeks after the migration. So if the service is transitioned at roughly the same time as the Application, the ITIL Service
support/ delivery process might need to support this rollback. It is expected that this would not be permitted, but a migration disaster could drive this
rollback from destination service, back to source service.
Deciding one of two main strategies could be driven by the quality of the CMDB as follows:
Scenario strategy 1:
The CMDB does not contain sufficient information at CI level (inc. CI relationships) to underpin a successful App migration.
(note a sub-scenario here could be that FITS management signoff the risk that CMDB data is not of sufficient quality, but FITS migrations will use it anyway.
The risk might likely be owned by the App owner / App SME at this stage. Go-to scenario 2 if this is the case)
Impact to ITSM:
Since the migration is supported by discovery information held internally within the Central Migration Team, all ITSM process scenarios for this app can be
paused at the DP6 (Point of No Return for App migration) because management of this App is owned by the migration team until successful migration.
Furthermore, the central migration team has the most current App technical info because it has discovered it.
The App service detail specific to this App should be amended/stopped at this point to stand down each Application Service element as it reaches the DP6
(Point of No Return for App migration).
The service transition team should be ready to “bring into service” the Application as it passes DP9 Post migration review, with the DP3 (discovery detail and
application profile at CI level) documentation being added to CMDB at it’s new incumbent service destination point.
An example discovery document (DP3 supplier collaboration ) can be found here:
The risk of the Application profile being incomplete and inaccurate and causing technical unknowns to the migration is mitigated through asking suppliers to
complete their specific details within their own space.
When all discovery information is added by all suppliers, then all suppliers should attend a review meeting to signoff the accuracy and correctness of the
DP3 document.
The Annex C at the end of the above DP3 template gives an example of a blank application questionnaire that should be sent to App owners. App owners
should have the responsibility of completing this and returning it to the Central Migration Team.
Microsoft Word
Document

8. 8
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
Considerations: Service Management for Applications / App delivery
Scenario strategy 2:
The CMDB does contain sufficient information at CI level and can facilitate a successful App migration.
It is possible to deliver an Application service with the minimum service wrapper of CFGM, CHGM, INCM.
It is suggested to reduce complexity, that process scenarios touching the migrating App are paused at the DP6 App migration
point of no return stage (excluding CFGM, CHGM, INCM). At this point the App is managed by the Central Migration Team.
The Service Transition Team should be ready to pause “as-is” scenarios outside CFGM, CHGM, INCM for other processes (i.e.
RELM, CAPM, AVAILM,ITCM, ITSM, ITFM)
Change request approval is part of the DP6 Point of No Return success criteria. CI’s and their relationships have been reviewed
in the change record along with an impact analysis of the change. After a successful migration, the CI’s should be allowed to
update in CFGM CMDB ready for future CMDB data sync.
After a successful migration and signoff of it by the business, the service should be transitioned as per the service transition team
process, policies and procedures.

9. 9
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
Considerations: The Service Transition Team
To get project traction, and to reduce complexity, App migrations might take place individually per App.
It might not be true that an App migration service (encompassing multiple apps) can be transitioned in a “big bang” approach with
all Apps within that service migrating simultaneously.
The capacity of support groups/teams will likely dictate that Apps should be migrated individually in a decant to recant approach.
With this in mind, Apps might need the capability of rolling back at physical, logical and service management level after the
migration event.
Since multiple Apps probably exist in App services (i.e. 1 x service per app may not exist), it may be a requirement to keep the
service running until the last App for that service migrates (i.e. the last person out turns off the lights).
Special interest should be taken in determining the quality of the CMDB in the Application space, because the strategic app
migration options chosen (in service management considerations slide) could impact the Service Transition strategy for
Applications.
If Application SLA banding is in use, it may be beneficial to group Applications by SLA Band of Availability. i.e. An application
migration, migrating a Platinum SLA band level Application may need to be more vigorously controlled / governed through it’s
migration path than a Bronze Application. This is to ensure it’s Availability to the user does not breach the SLA tolerances.
The Service Transition Team may want to align migrations where possible into SLA Bands of Applications i.e. Platinum, Gold,
Bronze, Copper could be all grouped together.

10. 10
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
Considerations: Testing
• During a migration, perhaps limited UAT testing is Available? Perhaps teams involved will only get the weekend window to
migrate and test, before users login on Monday am. With this in mind, destination environments need to be fully operational
with UAT teams ready to test in their small windows. Hands on fixes from all technical teams is required during the migration
notably Firewall/Network/App 3rd
party, OAT and UAT teams.
• The availability and quality of CMDB should be considered when planning testing as this is a valuable source of baseline
information for the App. Testing completeness can be based around the App specific detail either in the CMDB or in the DP3
migration design document. If CMDB is not used then the DP3 document discussed in this presentation can be used in its
place.
• Testing of apps should capture in place testing (pre migration) and in destination testing (post migration).
• Any issues reported post migration should use results of pre vs. post migration to start a technical analysis of the issue.

11. 11
[INSERT PROTECTIVE MARKING]
[INSERT PROTECTIVE MARKING]
[Insert filename and version number]
More discussion
• Please contact Jay.Jackson@justice.gsi.gov.uk for further information.
Jay Jackson
FITS Programme - Service Design
Ministry of Justice ICT
2.35, 102 Petty France.
London.
SW1H 9AJ.
ddi: tbc
mob: 07742 633316
email: jay.jackson@justice.gsi.gov.uk