Application Server Migration Presentation

1. Migrating Enterprise Applications Between J2EE Application Servers Ajit Sagar Enterprise Editor, Java Developers Journal Founding Editor, XML Journal Senior Technical Architect, Infosys Technologies, Inc.

Facets of Migration

How We Got Here

J2EE Migration By Any Other Name

Migrating J2EE Applications

Migrating Enterprise Applications

Migration Methodology

Migration Planning

Migration Aids

Summary

Contents

Why Migrate?

Migration Concerns

Migration Requirements

Stakeholder Perspectives

3. Why Migrate?

New strategic partnerships

Product/Vendor upgrades

Increasing demands of businesses

Rapid technology changes

Performance requirements

Improved service to customers

Market pressures from competing vendors

4. Migration Concerns Will the integration with other components, products change? How can I achieve migration without impacting my current customers? How much will it cost? How long will it take? What technology / business benefits will I get after migration? My current application works fine. Why do I need to migrate? Where will I get skills / training for the migration? How will I accommodate the migration effort in my schedule? 5. Migration Requirements

Functional

Similar or better functionality

Minimum disruption to existing business services

Non-Functional and QoS

Similar or better performance

Standardization around IT strategy

Cost-effective solution

Rollback option

Minimum downtime of applications

6. Stakeholder Perspectives

Business Owners

Business impact

Downtime

New features

Technical Services

Performance and capacity planning

Deployment process

Skills needed to set up new environments

7. Stakeholder Perspectives

Enterprise Architecture Team

Architecture roadmap

Standards and governance

Application Team

Effort required to migrate

Required skills to migrate

Design based on new features

Additional work in an already busy schedule

8. Stakeholder Perspectives (contd.)

Application Server Vendor

Backwards compatibility

Product roadmap

Competitive advantage

Third Party Vendors

Compliance with new APIs

Program Management

Risk mitigation

Project management for analysis, planning, execution

Why Migrate?

How We Got Here

Migration Planning

Migration Aids

Summary

Contents

J2EE Evolution

The App Server Market

Role of App Server Vendors in the Organization

10. J2EE Evolution

Before Java 2, Java was simple

Complexity due to segregation into J2SE/J2ME/J2EE

Complex packaging and deployment

Some key upgrade drivers:

JSP 0.9-1.1

JDBC 1.x-2.0

Servlets 1.x-2.3

EJB 2.0

MDBs in EJB 2.0

Web Services support

11. App Server Market

A few years ago, there were 20+ major app server vendors

Now, for large organizations, there are:

IBM WebSphere

BEA WebLogic

Oracle Application Server

Sun One

The differentiation is in terms of technical capabilities, packaging,

corporate relationships, and cost 12. App Server Market (contd.)

Implementations and optimizations were done ahead of API releases

Some App Servers were late to adopt to the latest J2EE releases

e.g., IBM included EJB 2.0 support more than a year after BEA

App Server vendors solution stack includes offerings supplementary to Java

13. Role of App Server Vendors

Licensed product

Licensed product + consulting

Licensed product + technical services

Licensed product + infrastructure management

14. Contents

Why Migrate?

How We Got Here

Migration Planning

Migration Aids

Case Studies

Upgrade

Cross App-Server Migration

Cross Hardware/OS Migration

Cross Software Platform Migration

15. Upgrade

Phasing out support for previous versions

Compliance with latest J2EE standards

Standardization to consolidate version of Java APIs across the organization

Typical upgrade timeframe is every 12-18 months

Example WebSphere 3.5 to 5.1 upgrade

16. Cross App Server Migration

Vendor solution stack offerings

Cost advantage

Examples migration to Sun One, migration to JBoss

Consolidation to one application server for all applications

Corporate agenda/partnerships

17. Cross Hardware/OS Migration

Migration to cheaper hardware

Example migration to Linux/Red Hat, migration to Windows 3K servers

Migration to higher performance hardware

Migration to one-stop shop

Example IBM, Sun

18. Cross Software Platform Migration

Migration from mainframe to J2EE application server

Migration from .NET to J2EE application server

Migration from PowerBuilder to J2EE application server

This can be categorized as a rewrite/re-architecture, and not migration 19.

Why Migrate?

How We Got Here

Migration Planning

Migration Aids

Case Studies

Contents

Application Footprint

J2EE Migration Considerations

Integration Components

Third Party Vendors

20. Application Footprint J2EE APIs Messaging Security/SSO Portal Legacy Reporting Other Internal Applications Workflow External Applications 21. J2EE Migration Considerations

Packaging IDE specific, vendor specific

Authentication and Authorization mechanism

Off the Shelf Components

System Interfaces

Third-party libraries

Persistence Mechanisms

Changes to specifications

Use of proprietary technologies

22. J2EE Components and APIs

Servlets

Web Services APIs

23. Integration

Security

In-house frameworks and components

Integration with legacy systems

24. Third Party Vendors

Compatibility with target application server

Compatibility with target hardware/OS

Why Migrate?

How We Got Here

Migration Planning

Migration Aids

Summary

Contents

Characteristics of Enterprise Applications

Large Scale Migration Challenges

26. Characteristics of Enterprise Applications

Varying levels of complexity

Enterprise Applications are distributed applications

Involve varying versions of technologies and APIs

Unique integration requirements

Integration with third party packaged products

Integration with in-house frameworks and components

27. Characteristics of Enterprise Applications

Application teams have differing levels of expertise

Can require communication between heterogeneous hardware/software platforms

Typically involve multiple stakeholders

Dependencies between applications in a portfolio

Usually have stringent SLAs

Complex testing requirements

28. Large Scale Migration Challenges

A structured migration attempts to apply a one shoe fits all approach

Different application teams see different benefits/challenges

Schedule and functional dependencies make overall planning very complex

Infrastructure planning is inherently complex

A substantial investment is required for the migration

Why Migrate?

How We Got Here

Migration Planning

Migration Aids

Case Studies

Contents

Migration Phases

J2EE Migration Methodology

30. Migration Phases 31. J2EE Migration Methodology 32. J2EE Migration Methodology Highlights

Leverages tools available from the vendor

Incorporates phased approach for migration

Enables better planning and scheduling

Provides end-to-end migration solution

Aids in migrating portfolios of J2EE applications

Substantially mitigates migration risk

Why Migrate?

How We Got Here

Migration Planning

Migration Aids

Case Studies

Contents

Migration Approach

Migration Analysis

Prioritization

Migration Scheduling

34. Migration Approach Infrastructure Set up Program Management Testing Services Technical Migration Perform unit testing for components Prepare migration strategy Migrate codeto new environment Integration, UAT, stress and regression testing Develop sizing and scheduling estimates Collect Information on Testing processes, Tools Project management, Risk management, Resource management, Knowledge management, Change management and Leadership, Quality & Metrics Management Understand As-Is and To-Be Infrastructure Program Managed Application Server Migration Tracks Perform IDE testing for application Analysis, Planning & Scheduling Code Migration & Deployment Testing and Release Transition and Warranty Deploy codein new environment Define testing strategy & plan Complete DRR request and deployment map Verify availability of target environments Review and Standards Prepare review documents, participate in review check points and work with standards groups, to align the application architectures with technology standards within the organization. 35. Migration Analysis 1 2 3 4 5 6 7 2 3 4 5 7 3 3 2 3 4 5 6 7 2 3 4 7 A B C G D, J E F H N I,L M K Risk Time Activities 1 => Application SMEs not known2 => Migration effort not known 3 => Schedule and functional dependencies not analyzed 4 => Infrastructure requirements not determined 5 => Newfeature benefits not evaluated 6 => Application Characteristics not known 7 => Alignment with standards not assessed Risks A => Identifyapplication stakeholders B => Prepare sizing template C => Feedback and finalization of responses D => Analysis of data collected E => Prepare a feature cost vs. benefit analysis F => Analyze third party tool dependencies H => Analyze integration dependencies I =>L => Prepare Training Plan M => Get Stakeholder buy-in N => Finalize strategy and migration plan Activities A structured approach mitigates the risk of migration and optimally leverages the features of the new platform Migration strategy, planning, & execution 36. Detailed Planning Activities Project Inception Preparation of application inventory and templates Information Gathering Team interviews and data collection Analysis Sizing, estimates. and schedule Prepare and finalize application inventory Refine pre-defined sizing and analysis templates to for enterprise application migration needs Review & Publication Estimates Review, publication and presentation to stakeholders Meet with subject matter experts for each application to capture application characteristics in the templates Analyze and estimate testing and training efforts for the development and production environments Meet with application teams to refine the process for estimating the effort Prepare migration cookbook for WAS migration specific to target environment Produce migration estimates based on dependencies on Java architecture components, 3 rdparty libraries and products, and integration requirements Refine and enhance sizing and effort formulas and factor in each applications business constraints to prepare initial schedule Collect information on existing strategy for individual applications Present migration plan to key stakeholdersFactor in per-application project costs and overall PMO costs Migration Estimates and Analysis Workbook Application characteristics Executive presentation Migration estimates, schedule , Analysis Workbook , andMigration Cookbook Determine the future states for the APIs and third party versions based on enterprise architecturestandards ACTIVITIES TASKS OUTPUT 37. Example - Migration Analysis Workbook Illustrative This workbook constitutes a framework for WAS migration analysis and estimation. It consists of templates to capture the various facets of an enterprise level migration involving applications owned by multiple portfolios/LOBs The contents of this analysisand estimation workbook can be customized for the client, based on the requirements and the scope of the engagement. Worksheets can be added or deleted from this workbook 38. WebSphere Upgrade - Transition 3.5x 2.03 4.0x RecommendedEnterprise Architecture Components maynot be used MQ Development Environment VAJ WSAD Source Code VAJ CVS IDE App Server Versions Run Time Environment Sun Solaris, UNIX APIs Servlets 1.x 2.1 2.2 JSPs 0.9 1.0 1.1 EJBs 1.0 1.1 JDK/JRE 1.2.x 1.3.x 5.1 Recommended JAT Components used MQ Development Environment WSAD 5 Source Code CVS IDE App Server Version Run Time Environment Intel, Linux APIs Servlets 2.3 JSPs 1.2 EJBs MDB 2.0 JDK/JRE 1.4 CURRENT STATE FUTURE STATE J2EE 1.3 UDB 7.x Sybase UDB 8.x Sybase Illustrative 39. Migration Prioritization Technical Complexity Business Criticality Quadrant 4 Technical Index = Low Business Index =Low Quadrant 1 Technical Index = High Business Index = High Quadrant 2 Technical Index = Low Business Index = High Quadrant 3 Technical Index = High Business Index = Low App 1 App 5 App 4 App 3 App 2 App 7 App 6 40. Cost Estimates

SUMMARY

Application Migration Effort (code migration and testing) =20,939 hours

Total cost =USD 9,240,640

Largest cost= Application 7 (USD 2,304,834)

Smallest cost = Application 15 (USD 71,831)

High hours (due to benchmarking requirement) = Application 29 (2,380 hours)

External costs for are not factored in

Updates from some applications may change the estimates

Application Migration includes code migration and testing

Project and PMO costs include training

Illustrative 41. Migration Schedule Illustrative 42. Contents

Why Migrate?

How We Got Here

Migration Planning

Migration Aids

Summary

Migration Frameworks

Migration Tools

43. Migration Aids

Automated migration tools

Migration Service Offerings

Training

Migration guides

Migrating to WebSphere V5.0 An End-to-End Migration Guide

Migrating J2EE applications intoWeblogicproduct family

Migrating J2EE applications into Sun Java System application server product family

Moving a WebLogic Server Application into WebSphere Studio

44. Migration Frameworks

Analysis and Estimation frameworks

Planning and Execution frameworks

Benchmarking frameworks

Why Migrate?

How We Got Here

Migration Planning

Migration Aids

Summary

Contents

Migration Best Practices

46. Migration Best Practices

Program manage your migration

Prepare your arsenal

Invest in a planning phase

Communicate and educate

Get everyone working towards the same goal

47. Migration Best Practices (contd.)

Prepare questionnaires and templates for gathering migration requirements

Consider the least common denominator in aplain vanilla migration

Invest in specialized training for migration

Wade the waters before jumping in

Always leave a back door open

48. Thanks Ajit Sagar [email_address] http://www.ajitsagar.javadevelopersjournal.com

Application Server Migration Presentation

Technology

Transcript of Application Server Migration Presentation