Bringing Development and Operations together
When transforming legacy workloads, a number of options can make the difference between success and failure with the migration project itself as well as materially affect the amount of value realized in the post migration production and further modernization. The choices made around deployment models are one of the most important options to be considered
In most cases, the initial transformation step, the migration, is executed directly, limiting changes and customizations as much as possible, substantially reducing risk and resulting in a manageable project.
That said, even a straight forward migration still has an impact on your organization requiring you to allocate resources in project management, testing and release to production as well as necessitating one off functions such as migration specific Q&A and support throughout the project. One critical factor for success is applying a DevOps approach to the deployment. In this case Development and Operations functions should be incorporated into the Migration/Deployment team from startup and engaged through the deployment including throughout the testing process. This is especially effective when Operations assists in setting up and configuring the test environment in such a way as to mirror production deployment scripts, security and monitoring software.There can be no doubt that getting your Development Team collaborating closely with your Operations/System Administration team is one key success factor for achieving your legacy transformation (migration and modernization initiatives). Check out the blog post: Win IT together; a legacy transformation project as the perfect catalyst for leveraging DevOps
Some other important decisions will need to be made around deployment models:
In the case of big bang, all the migrated workloads are deployed at the same time. This means that the deployment team and resources only need to be assembled once and there is no need for temporary integration/interfaces between phases that are deployed and phases still remaining on the legacy platform. However, Big Bang deployments are much harder to roll back if something goes wrong. Problems also tend to be more wide spread if they arise after cutover because they can affect all areas (all branches and/or multiple workflow processes).
Allow the migration to be broken up into groups by geography/location or by discreet segments of the overall workloads being transformed. In the case of phased deployments, a few locations or workloads can be brought online at a time allowing for the easier/standard groups to go first and shake out and resolve as many post cutover issues as possible before proceeding to deploy the more complex or higher visibility phases. However, agile deployments require a longer cutover period including keeping deployment resources allocated for longer periods of time and also, often require the creation of complex, temporary interfaces to keep the deployed groups in sync with the groups pending deployment.
On Premises Deployment
Allows you more control over the brand and type of infrastructure as well as the setup, configuration and compliance with your organization’s policies. For organizations with a very efficient, optimal and cost effective infrastructure/data center group On premises deployments can be more secure and largely offer optimal performance and control. However, in most cases organization’s that are in need of modernizing do not have data center management as part of their core competency or competitive advantage. Therefore On Premises deployments mean continued, sizable CapEx investments
Public, Hybrid or Private Cloud Deployment
Asysco has extensive experience with all different options. We have worked with a number of key integrators to build a transformational model that consists of:
- Staff augmentation to allow you to continue on your current roadmaps whilst key resources are made available for the migration.
- Agile and DevOps deployment models.
- Full operations management of the new environment.
- Financial engineering moving CAPEX to OPEX for both the existing legacy book value as well as all the components mentioned above resulting in a lowered cost per transaction/policy/timeframe
from day 1.