NextGen Consulting

Migrating Amdocs CRM Classic to Smart Client (part 2)

In the first part of this post we discussed some of the business and technical drivers for migration from Amdocs Classic to Smart Client technology . We discussed the preliminary information needed for migration assessment, as well as the required resources for such assessment.

This part describes the following migration assessment aspects:

• Migration Assessment Planning 
• Migration Project Planning
• Phasing
• Migration Techniques

 

Migration Assessment Planning

The purpose of the migration assessment is to provide the management a Statement of Work, Project Plan, Hardware sizing and Estimate for the migration of the current customized Classic implementation to the Smart Client platform.

A typical migration assessment can broadly be divided into the following stages:

• Information Gathering
• Map the Gaps
• Plan Implementation and Deployment

 

Information Gathering

• Gather information about processes, functions and architecture.
• Gain thorough understanding of functional use of the current Classic client Implementation – solution overview.
• Review current functional and technical requirements and identify specific requirements that must be considered as part of the migration.
• In order to limit the project scope it is necessary to limit the inclusion of significant amounts of new functionality. Yet, the introduction of new functionality may be one of the key business drivers to migration.

 

Mapping and Gap Analysis

Map the existing functionality in the currently customized solution to the OOB Smart client application.

The goals of this task are as follows:

• Identify customizations that could be replaced by existing OOB Smart Client functionality.
  The goal is to move away from complex customization in favour of OOB in order to reduce TCO.
• Identify required baseline forms that are not available in the Smart client OOB application.
• Identify customizations that are to be migrated as is.
• Identify customizations that should be re-written.

 

Interface and Integration Analysis

• Identify Client side integrations (integrations need to be re-written)
• Identify all Backend interfaces and integrations (minimal affected by migration – all the old interface techniques are still supported)
• The main efforts with interfaces are data model changes. 

 

Data migration

• Identify data that needs to be migrated and / or restructured.
  For example: CIM interaction model.
• Infrastructure Analysis – the current infrastructure must be understood and documented.
• Identify existing infrastructure which can be re-used.
• Identify additional required infrastructure.
• Identify required performance, sizing, fail-over and high availability (as per stage 1).

 

Implementation and Deployment Plan

• Determine the ideal way to carry out and deploy the migrated solution;
• Consider  big-bang Vs. gradual, phased migration
• Consider using Classic client co-existence with Smart Client.
• Determine the expected level of support to be provided during deployment. 
• Assign responsibilities for testing, training etc.
• Produce a high level project plan and costs estimation.
• Return on Investments (ROI) Analysis –provide the management with an understanding of the expected costs and associated benefits.
• Scope the migration task – produce a Statement of Work.

 

Migration Techniques

A brief overview of the techniques used when migrating from Classic to the Smart Client Application. 

 

Migration Areas

There are three main areas of consideration:

• UI (Forms)
• Business logic (forms code)
• Common business logic (Global code modules)
• Interfaces

  

UI (Forms)

The techniques used in migrating Classic application to Smart Client vary on a form by form basis. It is determined by the work done during the analysis. 

Some forms will be completely re-implemented using the Smart Client designer, others will be migrated by customizing a derived version of an existing Smart Client Application form and some will not be migrated at all.

 

Business Logic

It is likely that the logic embedded in custom Classic (Clear Basic) code has NOT been written with a separation of UI logic from business logic.

The Clear Basic code has to be reviewed and converted to take advantage of the newer Java technology.

 

Interfaces and Integrations

Most of the following integration techniques are still supported in the Smart Client backend (application server and database) and may need some changes to the code base:

• DB level integrations
• Tuxedo – CBCode on the server
• High Level and Low Level APIs
• Dataex
• Middleware solutions
• Email Manager
• Business Rules
• CBBatch
• CBO (Core Business Objects)

  

Since the Tuxedo server is no longer required as part of the Smart Client server Architecture, it  is recommended that the Clear Basic code running in the Tuxedo environment will be rewritten as Java code. 

However, if CBCode is heavily used on the server-side in the current implementation, it may be best to leave Tuxedo in place allowing the code to be migrated overtime and decommissioning of the Tuxedo server at a later date.

 

Client Side Integrations

The client side integrations need to be completely rewritten.

Classic client side integration techniques not supported directly by Smart Client:

• Button Actions
• ActiveX Server
• DDE
• DLL’s

Some embedded ActiveX (com) components can still be used in the Smart Client Application within the Smart Client Internet Explorer control. There are also 3^rd party solutions for bridging Java and DDE.

  

Migration Project Planning

Implementation

1. Prepare Development / Test Environments
    
2. Upgrade Database, Prepare Repository
    
3. Merge Repository
    
4. Import Languages and Locale-specific Objects into Smart Client UI (form properties, style properties file)
    
5. Migrate Custom Client-side Scripts to Script Manager or APM server Scripts
   • Applet Scripts
   • Scripts that reference the UI or Desktop context
   • Embedded ActiveX Controls
        
6. Outbound / Inbound COM
      
7. Update Interfaces and Integration Scripts
      
8. Perform Testing – Unit, System, Integration
     
9. Performance
      
10. Perform Production Environment Sizing review
       
11. Perform User Acceptance Testing
       
12. Develop Training (End Users, Help Desk)
       

 

Phasing

The concept of gradually phasing the migration (vs. Big Bang approach) is very appealing.  On the surface it would seem to be the lowest risk way to proceed.

 

Phased migration allows customers to leverage browser apps where ROI is highest

• Prioritize based on business needs, ROI
    
• Lower up-front costs
     
• Less disruption to users, IT and infrastructure
     
• Reduced Risk: Phase in smart client to keep organizational and infrastructure change manageable
     
• Convenience: Incorporate smart clients at your own speed – in phases, by groups, by functionality, etc
     
• Flexibility:  Leverage Smart Client applications immediately where needed, without disrupting productive client-server users
     
• Financial Protection:  Leverage current infrastructure.  Migrate users as infrastructure investment shifts
    

 

Organizations often have a specific time-frame in mind for a project whether it is a migration project, upgrade project or implementation project.

It is often impossible to fit within the required time frame with a big bang approach, depending on the complexity of the current implementation.

Existing implementations are moving goals – customisation continues in order to support the day-to-day business needs. 

Pro

• Lower risk
    
• Easier to manage people and change aspects, don’t need to train everyone in one go
    
• More manageable, phases are smaller and take less time to deliver
    
• Reduced strain on existing resources, testing, support etc.

   

Con

• Higher risk
    
• Increased cost due to increased project overheads
    
• Increased infrastructure may be required – can’t reuse existing servers if they are still supporting Classic client users

  

Phasing Methodology

Different methodologies apply for each organization, depending on their implementation. Consider the following factors:

• Is the Call Center blended or specific teams are used?
  If specific teams are use, it would lend itself to phasing.
     
• Are separate areas of the application used by separate teams?
  If not separate teams, it is more than likely phasing will prove to not be a viable option.

  

Migration Estimate

Effort estimates are based on design, build and unit test in man days. 

Areas to be considered for inclusion in the estimate are discussed in the following sections.  Where appropriate a sample table has been included indicating the type of information that should be included in the estimation for the migration effort.

 

Assumptions

When assessing which UI forms should be migrated it is important to keep in mind the size of the user community that will be using the forms.

 

Integrations

• Interfaces                                    
  Each interface should be considered in the estimate, based on  earlier analysis.
    
• Client-side Integrations        
  Each identified client-side integration needs to be included in the estimate, as the UI is changed; each requires some level of  effort.

 

Forms

For the purposes of migration estimation the forms used within the current implementation are categorised as follows:

1. Customization / Forms to be migrated
2. Customizations / Forms to be re-implemented
3. Customizations / Forms that will use OOB product functionality and not be migrated.
4. Baseline forms to be used that are not in the Smart client application.
5. Customizations required for new requirements

 

Global Code Modules

Code modules may need migration depending upon the chosen approach.

• Global code is run via Tuxedo
• Global code affected by data model changes 

 

Note that code modules required by new requirements should be accounted for in the Forms section, not in this section.

 

Data Migration

Data migration may be required based on the functional mapping and gap analysis.

For example, migration to the new interaction model, migration from custom objects to OOB objects, migration required due to more requirements.

 

Scripting

• Effort required re-implementing existing scripts,
• Effort required implementing new scripts.

 

 

Automation (Process Manager)

• Effort required for creating new Process Manager’s processes as required using OOB functionality.
• Effort required migrating existing Process Manager’s processes to new version of PM. 

 

 

Additional Considerations

Data Model

Changes to the existing data model may be required depending on the functional mapping, gap analysis and additional requirements.

 

System Testing

• Training
• Online Documentation
• Project Overheads