Client Server — Technical Migration Checklist [Java Example]

Purpose of this document

In addition to the functional maintenance of applications, there are always necessary technical upgrades, for example application servers, databases, security features and the like.

The necessary activities and processes are strongly dependent on the respective client, but can still be found in a similar form almost everywhere. Accordingly, it is important to know and observe these topics already during the proposal phase.

Please keep in mind that individual activities are also performed by other teams / providers and can have a significant impact on the schedule. (also for agile work)

Client Blue Print

Questions / Checklist

• Is there a migration guide from the client?
• Are there master solutions that need to be used?
• Are there deployment processes or CI:CD pipelines to be used?
• Which frameworks have to be updated or exchanged?
• Can older versions still be used, for example JSF 1.x on new application servers?
• Are there new safety requirements?
• Are there new requirements regarding authorization and authentication?
• Is the code quality checked and what happens to the old code?
• Are certain components no longer allowed, such as local queues?

Example:

Upgrade Java application server including JDK; logging framework could be reused; new portal integration using new authorization and authentication components; code quality must be checked upfront — should stay minimum at the same quality; because of heavy extension usage old JSF 1.0 could be deployed on new server

Preparation — Server Ordering and Planing

Questions / Checklist

• Is there a current architecture diagram, who is responsible for the update?
• Master solution? Who takes care of certificates and Co?
• Who orders the new component? Who has the rights?
• Will there be parallel activities, for example functional maintenance?
• Who is responsible for the final merge and any incompatibilities?
• Does a documentation exist and does the form fit?
• Are the new components compatible to the current components, for example to your CI:CD pipeline?
• Are there responsible persons who want to validate a solution in advance, for example architects?
• Are there any other stakeholders? (startup manager, test manager, operational responsible, …)

Example:

Migrations concept using the actual master solution should be created upfront, will be validated by the responsible client IT architect; operational responsible will handover current documentation, must be updated to latest style guide and specifications including technical updates; parallel functional maintenance by 3rd party

Interfaces and Batches

Questions / Checklist

• Can there be problems with parallel operation of the old and new solution? Or is it impossible?
• What are the effects if batches fail or have increased run time?
• Are there dependencies / workarounds — backup / fallback plan in place?
• Are the interfaces technically changed? Who needs to update clients?
• Who is responsible for coordination with the interfaces?
• Do the interfaces have capacities for possible changes and Tests?
• Are there critical processes that must not be interrupted?
• Do new components have to be registered, for example filters on server names?
• Are there new safety standards?

Example:

SOAP web service replaced by REST, clients must be changed; parallel operation is possible when batch jobs are activated on one cluster only; 1 of 10 interface system does not have maintenance partner at the moment (old application); only actual cipher suites are allowed in new master solution, clients need to use them

Testing (Functional, Approval, Penetration)

Questions / Checklist

• What specialist knowledge is required?
• Where do we get test data from? Are interfaces involved?
• Are there requirements for automated tests? Code coverage?
• Do certain frameworks have to be used?
• Do load tests have to be performed?
• Any other approval test required? (for example multiple projects on same OS / hardware)
• Is there any penetration test to check security? (Cross-Site-Scripting, SQL injection, …)
• Who executes the tests, are third parties involved? Do they have lead times?
• Do the testers have access to the test or integration systems? Can the data be used?

Example:

Test preparation must be done in interface system, could be done by functional department only; Integration data to old, must be updated in all involved applications upfront; approval required, migration team has to record automatic test scripts; penetration test has to be done by third party with 2 months lead time

Go Live and Hypercare

Questions / Checklist

• Are there any dependencies to interfaces? Do you need a time schedule?
• Are there any dependencies to functional departments?
• Must knowledge transfer be coordinated?
• Are there ongoing monitoring that need to be adjusted?
• Is there a Hypercare phase?
• Who is responsible for accepting user problems or tickets?
• Are there defined Service Level Agreements?
• Who informs users about innovations? (release notes)
• Do favorites, portal links or other external links have to be changed?

Example:

Application deployed in parallel using new master solution; 3 interfaces partners have to change their configuration during Go Live; knowledge transfer to operations required; monitoring tools must be extended to new solution; fallback to old version should be possible; Hypercare 2 weeks with default SLAs