Migration from Legacy Web client to UCI,
As we Microsoft announced by 10th of January legacy WebClient interface will be forcefully transitioned to UCI. Businesses were informed please start the transition process asap especially for live Environment which is undergoing some fixes and CR in support and should be considered as a mini-project.
Transition to new UCI might be taken lightly by some clients, but this needs to be addressed asap as although moreover, Mostly client-side customization will be affected by this transition and not everything will be deprecated in terms of js, workflow, etc.
But still, if we are in production and supporting fixes and changes, it recommended to slowly start the transition with validation and doing fixes with new UCI compatibility, as recently we went to start doing it for our client and there we realize it not that easy and smooth as it sounds although Microsoft did a fantastic job in slowly making everything new UCI compatible.
I am sharing some processes we followed for our client which were on legacy WebClient and support fixes +Â CR was under process. so the challenge was to work on support fixes Development, UAT testing, and Deployment to Production, and simultaneously all these fixes should be New UCI compatible and there were New UCI validation and customization happening in parallel.
- NOTE: I AM NOT SAYING THIS IS THE BEST PRACTICE TO FOLLOW JUST SHARING WHAT WE DID FOR SUCCESSFUL UCI TRANSITION AS PER CLIENT SUPPORT DEMAND AND BUSINESS,
Also, these steps will double up the effort of existing support fixes and New UCI Validation
We will divide our post 5 below:
-
Identify the most critical components and the commonly shared component (which almost no effect)
-
Setup Development environment for UCI upgrade and keeping in mind we also have to support fixes and CR to legacy WebClient
-
how to start UCI Transition validation and keep working on legacy WebClient with fixes and CR without overwriting each other changes/ customization
-
Deployment to QA and Production ( for both New UCI and Support fixes/CR)
STEP 1: identify the most critical components and the shared component (almost no effect) ,
By Identify Component which may or may not effect from the transition doesn’t mean we will skip the component listed in May, not have any effect.
The critical component will be the one which will be tested thoroughly looking into Error and creating a new component for change and functionally to work so it doesn’t affect the legacy app till we are ready for Production Upgrade, example –New form for the critical entity  ( our org was recently upgraded from on-premise environment and vendor worked on it left javascript as it is if it’s not giving error, even if the functionality was not working or partially working, So we opted creation on a new form for UCI so there would not be any conflict on legacy web client customization as we frequently fix the issue and deploy to Production)
We will go through more about how we segregated legacy web client customization with New UCI transition Customization in Setup Development EnvironmentÂ
Also below list was specific to customer current requirement/business process and might differ from business to business
COMPONENT WITH ALMOST NO IMPACT / LEGACY WEB CLIENT CUSTOMIZATION STRATEGY
1. ENTITYÂ
2. FIELDS
3. VIEW – Search result can vary and need to validate
4. QUICK CREATE FORM – need to be validated
5. RIBBON – There might be new buttons available which system user don’t want
6. BUSINESS RULE – ENTITY SCOPE – if the scope of Old Bussiness Rule is an entity then there is very less chance of an error, but scope with forms need to be reviewed and validated
7. WORKFLOW – As currently workflows are not going away we decided to keep the workflow as it is and will convert them to power automate once UCI upgrade is done. there would be a common issue with content referring to Org URL or record URL which where custom made, those need to be reviewed
8. PLUGIN – if the way using entity form is changed there right be 1 or 2 plugins which depend on js or another web resource/action and it best to check that customization.
9. POWER AUTOMATE FLOW – all-new requirement related to the workflow will be done using power automate
10 SYSTEM SETTINGS – There are some new features with can be managed using system setting and our old customization are of no use, better to update our system with this transition
11. SECURITY ROLEÂ
12. FIELD SECURITY
13. SOLUTION – For legacy WebClient we can maintain solution sprint wise and keep UCI component in different Solution and deployment strategy should be different.
14. REPORT- We didn’t find any issue regarding reports
CRITICAL COMPONENT / NEW UCI CUSTOMIZATION STRATEGY
1. NEW FORM – For critical entities with lots of web resources and flagged component, we decided to create a new form for UCI changes and keeping old form for legacy fixes and customization (we will be disabling legacy UI form once ready for a full upgrade)
2. QUICK CREATE FORM – This doesn’t apply to everyone but if required we can consider creating new quick create form for new UCI
3. NEW WEB RESOURCE – this is the most critical component and we will see in below Steps, how to work on start with Validation on web resource example Javascript
4. BUSINESS RULE – FORM SCOPE – We need to test Old business rule under form scope
5. SYSTEM SETTINGS –Â there are some common system setting differences related to Formates e.tc which we can cover in below steps
6. WORKFLOW – There could be a common issue with content referring to Org URL or record URL which where custom made, those need to be reviewed
7. PLUGIN – most probably there would be no issue with this component, but as mentioned before if the way using entity form is changed there right be 1 or 2 plugins which depend on js or another web resource/action and it best to check that customization.
8. SOLUTION – UCI UPGRADE PROJECT/sprint wise New UCI changes, keeping New UCI changes and Legacy WebClient customization if the different solution, as we will be deploying legacy customization to production but NEW UCI changes will be deployed to production at once. and we will know in the below steps who to prevent ourselves from the conflict in changes as both legacy WebClient APPÂ and UCI APP in the same environment.
STEP 2: Setup Development environment for UCI upgrade and keeping in mind we also have to support fixes and CR to legacy WebClient
There was 2 option for us to work with New UCI Transition customization and Validation and keep working on Legacy WebClient for Fixes and CR.
- Create 2 Dev Environment, 1 for UCI and 2nd will be for Legacy WebClient, but this would have resulted in an unequal environment at the time of production upgrade as there would be some changes in the legacy app and then a few changes in New UCI Dev environment. until we keep on merging them with each customization and that would be almost impossible to achieve especially when we had a large number of fixes and cr each week, this would be ideal for a freeze environment with new fixed or changes, So we adopted the second option.
- Create a new Model Driven app using legacy WebClient Sitemap and customization: so we will create a new UCI Model-driven app and same time keep Legacy WebClient so dev environment will be with the latest change regarding new UCI and Legacy WebClient
Only thing is to manage to work on customization of New UCI and WebClient without overwritten/damaging each other customization. we will check this in step 3.
Check 1. Create a New Solution with Legacy WebSclit Site map/ Model Driven app, which will be used for the creation of new UCI model-driven app
- Creating a new solution from make.powerapp.com
- Add Site Map or Model-Driven App in the Solution -> App -> Model Driven App
Solution -> Others -> SiteMap
- We Export the solution as a backup, but the main use of this solution will be when making Model-Driven app
Check 2. Create a new Model-Driven App for new UCI in same Dev Environment
- Creating a new solution from make.powerapp.com with name UCI UPGRADE PROJECT
- Create a new app and select use Existing Solution,
- We will select a previously created solution with site map.
We have 2 apps in same DEV ENVIRONMENT, so We can work on new UCI model-driven app for validation and customization and Regular legacy WebClient App for Fixes and CR for Regular support.
Click Here for Full PostSTEP 3: how to start UCI Transition validation and keep working on legacy WebClient with fixes and CR without overwriting each other changes/ customization
So the most common issue will over following the above structure is
- when we will work on Legacy WebClient App for Support fixes and CR, it might overwrite the changes done for UCI Transition and the changes Done for UCI transition may overwrite changes done for Legacy Web client App
- The new fixes being done will keep on adding up even if those are not compatible with NEw UCI
I have put up some process point we adapted while working on the transition
Click Here for Full Post
