Introduction

This document is a guide to help customers to plan migration and of course later on to do the actual migration.

Migration Strategies

These are three possible strategies for a migration:

• Platform Migration
• Feature Migration
• Blue Print Migration

Even though these strategies differs in their methodology an overall migration strategy will be always a mixture of all those. Certain features cannot be reused from one version to another if the underlying model has changes dramatically. For instance Enfinity Suite 6.4 compared to Intershop 7.0. The content model has changed too much as it would be possible to reuse the old model. In this case it is necessary to do a feature migration if content is used. The same applies to lot of other functional areas like promotion, basket handling and order handling if migrating from Enfinity Suite 6.4 to Intershop 7.0

Platform Migration

Reason

A platform migration can be useful if the application is highly customized. Therefore only the core platform is used, which implies that as much as possible is reused from the existing functionality. This kind of migration is only recommended if most of the pipelines from the demo application PrimeTech were rewritten and not inherited from the B2C channel.

Advantages

• Fast and cost effective only if highly customized.
• Less testing effort as the API of external interfaces would not change.

Disadvantages

• No benefit from new frameworks and features.
• Higher maintenance for custom code.
• Still necessary to migrate certain core features if they are used, like basket and order handling.

Risks

• No development effort is undertaken towards the standard Intershop application.
• Higher maintenance effort for custom code compared to other migration strategies.
• Less Intershop support as only the platform is used and supported.

Feature Migration

Reason

A migration of features is useful if the application is close to standard and many custom-built features are now part of Intershop 7's standard feature set. In addition, it is recommended that a feature migration is done after a platform migration as a 2nd phase.

Advantages

• Less custom code, therefore less testing and maintenance effort.
• Improved, tested features from Intershop.

Disadvantages

• Evaluation is necessary whether the new features actually fulfill the given requirements.
• Needs to be a compromise between custom feature functionality and what is implemented in Intershop 7. Most likely, the custom feature functionality does not exactly match the implemented standard features.
• May require to migrate data in order to keep history data.

Risks

• New migrated features may not exactly match the previous implementation. This may require an additional modification of interfaces to 3rd party systems.

Blue Print Migration

Reason

A blue print or green field migration can be done if an overhaul of the entire site is planned at the same time. This may be necessary if business decided to change business flows substantially or to introduce other 3rd party systems into the IT infrastructure at the same time.

Advantages

• Existing knowledge of Enfinity and Intershop can be used to build an improved version on the new platform; more efficient, performance driven based on Intershop features.
• Reuse of components like pipelets or pipelines even considering their efficiency, memory foot print and performance.

Disadvantages

• Most complex migration with several unknowns.

Risks

• Generally, it is never a good idea to change many things at once. In case of an error, it is difficult to determine if the error is caused by the migration or by the changed business functionality.
• Highest effort of all migration strategies as in essence it is a starting from scratch.

Tools

Intershop

• Guide - 6.4 Enfinity 6 to Intershop 7 - Migration Best Practices#DBInit is used to initialize a new DB schema.
• Guide - 6.4 Enfinity 6 to Intershop 7 - Migration Best Practices#DBMigrate adapts DB entries to existing settings.
• Guide - 6.4 Enfinity 6 to Intershop 7 - Migration Best Practices#DBExtract extracts information from current DB schema.
• Guide - 6.4 Enfinity 6 to Intershop 7 - Migration Best Practices#DBDelta extracts information from two different DB schemas.
• Guide - 6.4 Enfinity 6 to Intershop 7 - Migration Best Practices#API Checker used to check if an API violates Intershop's API's.
• Guide - 6.4 Enfinity 6 to Intershop 7 - Migration Best Practices#DiffReport compares two versions of Enfinity Suite/Intershop.

DBInit

DBInit is using database preparers to create channels, preferences, import users, catalogs and products etc. These preparers have slightly changed as the concept of applications has been introduced in IS7. See com.intershop.component.organization.dbinit.preparer.ApplicationPreparer, for instance.

See also:

DBMigrate

The same as for DBInit applies to DBMigrate.

See also:

DBExtract

DBExtract extracts structural information as well as content information from an given DB.

The following ANT build targets are supported:

• db-extract: Executes all other targets in this order: db-extract-structures, db-extract-sources and db-extract-content.
• db-extract-structures: Can extract tables, views, mviews, sequences, indexes and constraint structures.
• db-extract-sources: Extracts functions, procedures, packages and trigger sources from schema.
• db-extract-content: Predefined database content can be exported via this target. The definition of what is being exported can be found and extended in %IS_HOME%/tools/dbdiff.properties.

cd C:\eserver1\tools\misc
C:\eserver1\bin\environment.bat
ant -f dbextract.xml

DBDelta

This build script contains all targets to analyze and compare database schemas created by the DBInit process.

The comparison of two schemas is processed in several steps:

1. Executes all queries defined in the config/queries.xml file.
2. Creates a XML file containing the results of the processed queries.
3. Performs the same steps as in 1. and 2. for the second database schema too.
4. Compares both analysis files (returning XML files).
5. Creates a XML file containing the comparison result.
6. Generates HTML pages visualizing the comparison result.

The result of analysis and comparison are stored in result/xml. The HTML-transformed comparison XML file is stored under result/html.

C:\eserver1\tools\dbdelta\standard\config\dbdelta.properties

cd C:\eserver1\tools\dbdelta\standard
C:\eserver1\bin\environment.bat
ant

API Checker

The API Checker is used to find violations of the Intershop APIs as well as custom APIs. But it allows also to compare, for instance, ES6 APIs with IS7 APIs. The API Checker is located in %IS_HOME%/tools/api_checker. To execute it, please open an ANT build shell and go to %IS_HOME%/tools/api_checker/build.

The following ANT build targets are supported:

• defineapi: Creates the API definition file under %IS_HOME%/tools/api_checker/apidefinitions called api.xml.
• checkapi: Checks the current API api.xml against another API definition reference-api*.xml (can be configured in %IS_HOME%/tools/api_checker/config/api_checker.properties).
• checkquality: Checks code quality of the API definition reference-api*.xml. Results are stored in %IS_HOME%/tools/api_checker/result/QualityWarnings.txt.
• checktemplates: Checks templates for security vulnerabilities. A white list can be configured for templates under %IS_HOME%/tools/api_checker/config/template-check-white-list.txt. Results are stored in %IS_HOME%/tools/api_checker/result/TemplateSecurityWarnings.txt.
• checkacl: Checks ACLs for security vulnerabilities. See %IS_HOME%/tools/api_checker/result/PipelineACLCheckResult.txt for results.

DiffReport

A DiffReport compares two versions of Enfinity Suite/Intershop. These are the artifacts which are considered:

• EDL's
• Pipelines
• Templates
• Pipelets
• Java Sources
• Property files
• ImpExp files
• Images
• Build tools
• URL rewrites
• Web services
• Localizations
• Components
• Pagelets
• Webforms
• Queries

Example DiffReport between Intershop 7.2.1.0.136 and Intershop 7.3.2.0.233

It lists:

• Bugs
• Improvements
• Development Tasks
• Release Notes

3^rd Party ETL Tools

• Altova MapForce
• Talend Data Integration
• Spectral Core Full Convert

Estimation

Estimating a migration project is always complicated. Many things need to be considered:

• How many artifacts (Java API's, Pipelets, Pipelines, Queries, Templates and Pagelets) have been changed, overwritten or are obsolete.
• What is the degree of customization?
• Is the code well documented and easy to read, understand?
• Are business processes described sufficient enough?
• Is it planed to do a Platform Migration, Feature Migration, Blue Print Migration or a mixture of all three?

A good rule of thumb is 25% of the original customization for a major step (like ES6.x to IS7.y) and 10% for a minor step (IS7.x to IS7.y). In case of a 1.000 men days project it would be roughly 250 days for a migration from Enfinity Suite 6.x to Intershop 7.y for instance.

Migration Tasks

Data Migration

If nothing else stated Intershop provides so called DBMigrate scripts to migrate data. Exceptions are major version steps like from Enfinity Suite 6.x to Intershop 7.x. In those cases it is necessary to cater for migrating data yourself. Within the Intershop 7 family it's enough to execute DBMigrate except for one version from Intershop 7.0 to Intershop 7.1. In 7.1 Intershop introduced a so called ViewContext which is used instead of Context Object Relation (COR). For this it is necessary to migrate data and code.

Code Migration

All the tasks for code migration are in order. Up until migration step Java and having a compiling code base it's impossible to work in parallel on it.

Cartridges

• Create new cartridges to get new build files.

Java

• Get code to compile.
• Comment out more complicated stuff to be able to work in parallel.
• Add TODO comments to find those areas where rework needs to be done because of source commented out.

EDL’s

• EDL definition has not changed.
• Several templates have changed like ORM in 7.3, regenerate code from EDL’s.

Pipelets

• No changes for Pipelet Descriptor, Pipelet Language Descriptors and the abstract Pipelet Class.
• Feature or API changes need to be taken care of.

Pagelets

• Needs to be changed as model has slightly changed in IS7.1 but not since.

Queries

• No change of the file format.
• New types for return mapping to retrieve BO’s

Pipelines

• Get list of custom Pipelines using standard Pipelines. Search for the tag <parent> (inherit) and <startNameRef> (call or jump) in custom Pipelines.
• Get DiffReport from Intershop to find out touched Pipelines and check out differences.
• Resave all custom Pipelines as Intershop Studio has slightly changed the order of nodes within the Pipelines XML.

Templates

• Standard Pipelines may return BO’s instead of PO’s with different method names to retrieve attributes.
• Use BO’s instead of PO’s where applicable.

JavaScript

• jQuery UI 1.8.19 is used in IS7.2. It’s not recommended to use more than one JS framework nor to use another jQuery version other than the one is used by Intershop.

Environment Migration

The recommended way to migrate an environment is to either install the new instance on new hardware or one the same existing hardware pointing either to a new schema or the existing schema.

The proposed strategy for going live would be:

1. Deploy Intershop 7.y instance with newest code.
2. Bring up maintenance page to stop incoming traffic from customers.
3. Shutdown Intershop 7.x instances.
4. Reconfigure Load Balancer to point to new Intershop 7.y instance.
5. Backup DB and if necessary import DB dump into new instance for 7.y.
6. Run DBMigrate on 7.y.
7. Startup 7.y cluster.
8. Test Intershop 7.y instance.
   1. If successful:
      1. Continue
   2. If not successful:
      1. Import DB backup dump.
      2. Reconfigure Load Balancer to point to the old 7.x.
9. Remove maintenance page.

Process Migration

With Intershop 7.4 a new concept for build, test and deploy was introduced. Intershop has decided to use Gradle as the build tool. With Gradle it is possible to release just certain components like a new Backoffice or a feature like a new or updated payment provider. This new tool may have influences on these processes:

• Development Process
• Build Process
• Deployment Process
• Automatic Test
• Release Cycle