Migration from Legacy Webclient to UCI – Unified client interface – Part 2 Start UCI Transition validation and keep working on legacy WebClient

So the most common issue will over following the above structure is

1. 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
2. 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

• For Validation on UCI and as per Business; we chose a strategy to go Entity wise to Validate components i.e web resource, Ui, etc for each entity starting with Account
  As our Account entity had lots of Web resource and not to miss most of the web resource were written 5-6 year back in on-premise org,
  So we Created New Form, coping Legacy Form for validation and changes- If we find any issue in an webresource , we do the changes in such a way that that customization is compatible for both Legacy UI and New UCI and maintain component in Bothe solution, Bux fix on Legacy WebClient and Solution on UCI upgrade project ( We were managing all these in User stories, Tasks, and Statuses which we used in final Production tradition )- If somehow Web resource customization can not be compatible for both New UI and Old WebClient (unsupported web resource I am assuming). We will create a new web resource which will be attached in new form and making sure it’s not impacting legacy WebClient app component or flow,
  then we will maintain a ticket in VSTS stating in final production transition we need to disable Web resource in Legacy WebClient, though We already created New form and new web resource and while production transition we have working webresource in New UCI form.

• 2nd Scenario can be as following, We received a bug/issue and this fix needs a change in  Javascript  (Web resource 1), and in parallel, our Validation and customization going on-> We will fix the issue in such a way customization is compatible for both Legacy webClient and New UCI and this way new customization will not be any hindrance in Production transition-> 1 thing to remember This will result in Double effort and Slow fix delivery and Client should be notified about these in advance.

Below Table contain some more info on the process we followed and again mentioning these are not Best Practice , was followed to take care business Support Demand and issue logs, as recently we were moved from On premise to Cloud with very old codes.

REGULAR APP/ OLD UI			NEW UCI
–  We will keep supporting and using existing UI on regular main.aspx page			– Separate App has been created using old UI customization
– For new issue or change request on OLD UI , Customization done should be compatible with OLD UI and NEW UCI			– we will start our validation, entitiy wise on new APP
– Compatible with OLD UI and New UCI means, Functionality should be tested in both OLD UI and New UCI. For example if we need to add filter on a lookup , testing will be done in both apps.			– Suggestion : New Prefix can be used to identify new changes “atcc_customization”
– if customization/development done can not be compatible with both OLD UI and NEW UCI at same time, 2 Seperate customizations will be done 1 for OLD UI and 1 for new UCI. We will Create a User Story Tagged as UPGRADE CHECKLIST , where we will maintain this customization was done separately for OLD UI and need to be removed/reviewed on Upgrade of QA.			– Will Create new “FORM” for each entity starting with Account and start our validation
– All new Issue fixes or Change Done compatible with OLD UI and NEW UCI  need to be kept in Sprint Solution with Postfix (UCI or any suggested)			– While Validation if Issue identified, Customization will be done so it should be compatible for both Old and New UCI, and changes and ticket will be added in Current Sprint (UCI)
			– if Customization/Development is done can not be compatible with both at same time, Separate customization for only UCI will be done where new webresource / component will be created for new form.
– All New Issue Fixes or changes Done which are not compatible with New UCI will be kept in Different solution “SprintName + Postfix (NONUCI)”			-All Customization done for UCI will be added in Solution “UCI UPGRADE PROJECT”