One of the most common Cloud Challenges are customisation on premise application. Many assessment done to existing on premise will reveal these reasons why you should not move to Cloud. However, the assessment approach has been done incorrectly. Instead, it should be telling you on how you need to move to Cloud.
We find what we want to see
A good cloud assessment approach will not be one sided. It should have a balanced data and strategy to give the reader the right materials to make a decision. This is to prevent the bias of “finding what we want to see”. It is common to reason that heavily customised application to remain on premise instead of moving to Cloud. Vice versa, findings often point that Cloud should only handle lightly customised application.
Strategy to Cloud
As products move to SaaS, users will be forced to move customised applications to Cloud. It is important to provide strategy on how to migrate the customised applications. Many Cloud assessment will use Big Bang approach to review if the application can move to Cloud. You should also request for other strategy to be included in your Cloud assessment approach like phase transition or pilot migration.
Cloud assessment approach is often bias and skewed towards Big Bang migration approach. You should consider for other migration strategy when you are conducting your Cloud assessment. Thus, this will provide you a better picture to decide if you can migrate to Cloud.
Cloud expectations is a requirement that is often missed out. Unlike on premise, we often forgotten that Cloud is a product with constraints. Before you embark on a major cloud migration, it is recommended that you conducted a review of your existing architecture and expectations.
Understanding your Customisation
The common challenge with Cloud migration is customisation of existing on premise product. These customisation are often lost in translation over the years for legacy reason. Some of these customisation would even be uncovered during the cloud migration. Thus, it is important to do a deep analysis of your customisation. One guideline is called CEMLI (Configuration, Extension, Modification, Localization, and Integration) framework by Oracle.
Prepare your Cloud Expectations
Cloud expectations requirement must be translated to your critical success factors. These expectations will determine the effectiveness of your cloud migration. It is common to realise these expectations are missing. The user expectations will also mitigate the risks from Cloud migration. One such cloud expectation will be business continuity and minimum disruptions to operation.
There is a relationship of customisation and cloud expectations. Cloud is a product and will have larger gap for heavily customised on premise application. Thus, you will need to set clear cloud expectations to mitigate these risks. One common way is removal of customisation in preparation for cloud migration.
Waterfall migration is the mainstay for on premise application. In recent years, migration is adapting to Agile with Cloud. However, it is common to see conservatives conduct waterfall migration with Cloud. What are the good and bad of waterfall migration?
The Good and Bad of Waterfall
The good parts of using waterfall migration are:
Traditional approach with fixed scope.
Increased redundancy with development and testing environment.
Increased testing and issue management.
Tight control of changes from one environment to another.
By using waterfall approach, you need to anticipate these bad situations that will arise:
Increased duration from additional environment setup.
Increase cost of maintaining and licence costs.
Unable to react to scope creep.
High reliance to critical path.
While waterfall migration is a tried and tested method, be prepared for longer duration and higher costs due to the environment redundancy.
OTM (Oracle Transportation Management) can be a big dilemma if we are moving to cloud or upgrading. It is a configurable system that allows customisation from small degree of change to major one. A major part would be your decision to upgrade or migrate to cloud from the amount of configuration or customisation done to OTM.
Many organisations would prefer to migrate to cloud for future support and upgrades. separate the customisation Cloud, like its name, really is cloud. You cannot foresee what will happen in Cloud until you are in Cloud. Your risk appetite will need to be high if you have done a lot of customisation on OTM. Prior your move to Cloud, a major task is to separate the customisation into REST services. How much time and effort will you invest? Should you forgo your customisation instead?
Upgrading OTM major version can be quite a slow painful experience. The 6.4.3 is the last available version that is non Cloud based. The decision not to move to Cloud usually lies with the amount of customisation done. The biggest changes from old version to 6.4.3 version are architectural, user interface (UI) and report server. The dilemma comes in the sequence of upgrade you want to take. Report server is now mandatory after the removal of embedded reports. Should you move your embedded report first or do together with upgrade? How much training period should you allow for the new UI? How much time will it take to fix your customisation during the upgrade?
OTM upgrade or migration to cloud is a painful dilemma. There is always a temptation to status quo the version due to the massive efforts to factor risk and change management. In many cases, you need lots of patience and alternate plans while you are upgrading or migrating.
Have you ever face with delta data during migration process between upgraded systems? There are several standard approach to manage these delta. These approach can from simple to complex.
The Simple Way
The simple approach is usually relative to cost. This suits small and mid volume transactional data. You can choose to do a straight cutover from source system to target system. The focus will be on the delta data that reside between the two systems. There are two ways to handle this.
Reconciliation of data between two system till the delta is cleared. These usually will take 2 to 4 weeks for the target system to reach a steady state.
Stop processing of delta data in source system and to proceed in target system.
The Complex Way
If you have high transactions and a huge system. It is time to invest to manage the delta automatically. Complex way will usually involve tools or transient ETL (Extract Transform Load) integration between source and target system
ETL tools are the most common approach to synchronise data at application level. It is automated and can be removed once steady state is reached.
Another method is the building of a transient application to handle the delta data. This application is focus to manage the delta data and ensure a smooth transition between the two systems
Anyone and everyone will overthink Delta migration. It is always wise and wiser to consider the approach based on your transactions and budget. After all, you cannot request to fly to the moon with an aeroplane.
Migration is a challenging project for many. With the Cloud model, there are plenty of migration to and fro on premises and Cloud. Some will try to migrate to a ERP type large global system only to find its constraint. Then, they will migrate it back to legacy. One common trend in these migration is often traditional approach. Instead, you can consider to adopt Agile migration.
Traditional migration adopt incubator or sandbox approach. It involves a waterfall model of Big Bang. Initial fixes are done in the upgraded system with sample data. Changes are then deployed accordingly to testing environment for UAT (User Acceptance Testing). Once signed off, the entire fixes are deployed in a Big Bang to production environment. For each fix, regression testing are conducted again from testing environment. Duration of project will be at least 6 months to a year.
Agile migration are pioneered by the Cloud trend. Lift and Shift is the most common migration approach. In this case, at least 3 cyclic runs are performed on the migrated production environment. Agile is adapted for the project approach. The duration is shorter and takes less than 6 months. Another Agile approach is incremental migration. Migration is done incremental or Agile to move from legacy to target system.
Many organisations or vendors will conform to traditional migration approach to mitigate risks. With growing trend of Cloud and Agile team, you can consider to use Agile migration. The Agile approach aims to minimise costs and duration. However, you do required experienced vendors and SME (Subject Matter Expert) to adopt this strategy.