Migrate > Migrating WebSphere Commerce Developer
Prepare to migrate WebSphere Commerce Developer
This section discusses important information you should review before you migrate the current WebSphere Commerce Developer v5.6.1 or 6.0 to WebSphere Commerce Developer v7.0
Before you begin
You must drop or disable all customizations other than foreign key constraints (views, summary tables, triggers, SQL functions, and SQL methods) on the WebSphere Commerce v5.6.1 or 6.0 environment before running the migration script. The following table summarizes the customization actions that are recommended for the customization, depending on the database tables you have customized:
- Use the drop action for these custom constraints
- Use the drop or disable actions for these custom constraints
WebSphere Commerce tables recreated during migration Other WebSphere Commerce tables Custom tables Foreign key A A A Index B D A Triggers, Procedure, View, Summary table, Function, and Methods C E E
- A
- WebSphere Commerce can migrate this customization. Leave the customization object as-is.
- B
- WebSphere Commerce can migrate this customization. Leave the customization as-is.
- ermReapply this customization after migration.
- C
- You need to reapply this customization after migration. The migration script does not migrate it, because JDBC has no corresponding API.
- D
- If the index has been customized as per the Database schema object naming conventions, WebSphere Commerce can migrate this customization – leave it as-is. Otherwise, manually drop the custom index before migration and reapply this custom index after migration.
- E
- If the customization does not refer to default WebSphere Commerce recreated tables, it can be migrated normally – leave it as-is. Otherwise, drop the customization manually before database migration and reapply this customization after database migration.
The following table lists the WebSphere Commerce tables that are recreated during migration:
From WebSphere Commerce v5.6.1 From WebSphere Commerce v6.0 BUSAUDIT, CACHEIVL, CATENCALCD, CATGPCALCD, EMLMSG, ICMREGDESC, ORDERS, ORGENTITY, PX_PROMOTION, REFKEYS, STOREENTDS BUSAUDIT, CATENTRYATTR, GEONDDS, INVCNF, STLOCATTR, STLOCDS CATENCALCD, CATGPCALCD, EMLMSG, ORGENTITY, REFKEYS CATENTRYATTR, GEONDDS, INVCNF, PPCBATCH, STLOCATTR, STLOCDS BUSAUDIT, CATENCALCD, CATGPCALCD, EMLMSG, ICMREGDESC, ORDERS, ORGENTITY, PX_PROMOTION, REFKEYS, STOREENTDS BUSAUDIT ATTACHMENT, BUSAUDIT, BUYSUPSEC, CATENCALCD, CATENTDESC, CATGPCALCD, CNTRSTORE, EMLCFG, EMLMSG, EMLRCPTS, EXPERIMENT, ICMREGDESC, INITIATIVE, INVOICE, MESSAGE, MSGARCHIVE, MSGSTORE, ORDERS, ORDPAYMTHD, ORDRELEASE, ORGENTITY, PAYSUMMARY, PICKBATCH, PRODUCTSET, PX_DYNATTR, PX_GROUP, PX_POLICY, PX_PROMOARG, PX_PROMOTION, REFKEYS, RLDISCOUNT, SCHERRORLOG, STOREENTDS, TCATTR, USERREG, WCSGBLDATA BUSAUDIT, CATENTRYATTR, GEONDDS, INVCNF, MBRGRPCOND, STLOCATTR, STLOCDS, TRDPSCNXML
Any customized foreign key constraints that have been added to the WebSphere Commerce environment are handled automatically by the migration script. The script drops these foreign key constraints at the beginning of the database tier migration. The foreign key constraints are added back at the end of the database tier migration.
Any customized indexes that have been added to the WebSphere Commerce environment are handled automatically by the migration script. The script drops these customized indices at the beginning of the database tier migration and adds them back at the end of the database tier migration.
- Back up the WebSphere Commerce development environment assets
Before you upgrade any software or transition any custom code, ensure you back up the WebSphere Commerce development environment.
- Upgrade development environment software
The first pre-migration step is to upgrade the software to the levels required by WebSphere Commerce Developer v7.0.
- Run pre-migration scripts
Before you run pre-migration scripts, ensure that you have a backup of the development database.
Next topic:
Migrate the WebSphere Commerce Developer database