IBM Cloud University 2017-IDPA009-IBM BPM Upgrade and Migration Made Easy

IBM BPM Upgrade and Migration made easy
Session IDPA009
Allen Chan, IBM Distinguished Engineer
Chief Architect, Business Process Management
Brian M. Petrini, Technical Offering Manager
IBM Business Process Management

IBM Cloud University 2017 | October
Please note
IBM’s statements regarding its plans, directions, and intent
are subject to change or withdrawal without notice at IBM’s
sole discretion.
Information regarding potential future products is intended to
outline our general product direction and it should not be relied
on in making a purchasing decision.
The information mentioned regarding potential future products
is not a commitment, promise, or legal obligation to deliver
any material, code or functionality. Information about potential
future products may not be incorporated into any contract.
The development, release, and timing of any future features
or functionality described for our products remains at our sole
discretion.
Performance is based on measurements and projections
using standard IBM benchmarks in a controlled environment.
The actual throughput or performance that any user will
experience will vary depending upon many factors, including
considerations such as the amount of multiprogramming in
the user’s job stream, the I/O configuration, the storage
configuration, and the workload processed. Therefore, no
assurance can be given that an individual user will achieve
results similar to those stated here.

… to deliver the end-to-end
customer journey
… built on an extensible
framework for innovation
and insight
… enabled by a platform for
rapid delivery and iteration,
led by the business
Digital Process Automation is…
IBM’s platform for rapidly creating business–led process apps
that deliver new levels of
customer experience and digital self service
Key attributes of the Digital Process Automation platform:
Customer
focus
Speed Scale

Digital Process Automation capabilities
Define customer journeys and business operations
to discover new opportunities for innovation
Design, automate and govern business
operations to deliver a scalable, consistent
customer experience
Analyze data and events
to augment knowledge work
and take the right action at the right time
Actionable
Insights
Collaborative
Discovery
Business Automation
Digital
Process
Automation

Ordered Sequence
of Activities
Some Unordered
(Ad-hoc) Activities
Some Activities
with Ordered Steps
Unordered Set
of Activities
Next Step Determined ByProcess Model Knowledge Worker
Data
Structured
Business Objects
Unstructured
Documents
5
Spectrum of Process Types

6
Continuous Delivery Strategy for IBM BPM
Responsive
Portal and UX
IBM BPM on
Cloud
Case & Content
Integration
Federation
Server
Process
Federation
Server
Web-based
authoring
Spring 2014
BPM 8.5.5
Spring 2013
BPM 8.5.0
Spring 2015
BPM 8.5.6
Spring 2016
BPM 8.5.7
2Q16 3Q16 4Q16
REST and
Open API
1Q17 2Q17 3Q17
Process
Analytics
RPA
In BPM 8.6 we moved to continuous delivery support.
https://www-01.ibm.com/software/support/lifecycle/cd-policy.html
8.6 has 3 years of standard support and at least 1 year of extended support.

What is BPM 8.6?
1. Just released in Sept, 2017
2. In-place upgrade from all prior BPM 8.5.x releases
3. BPM 8.6 can be considered as CF 2017.09 - Subsume BPM 8.5.7 as the next Cumulative Fix
(CF) in the BPM continuous delivery pipeline.
4. BPM 8.6 is on a continuous delivery licensing terms with a new support lifecycle (3 years
standard support + 1 year extended support).
5. Support Java 8 only - end of support for Java 6 (April, 2018), and Java 7 (Sep 2019).
6. Simpler licensing scheme
1. Both Standard and Advanced features are included in the same license
2. Process Server and Process Center have the same price
3. No separate license required for web Process Designer
4. Eclipse Process Designer and Integration Designer will still require separate licenses.
7. Faster than 8.5.x - based on BPD, Ad-hoc and BPEL benchmark

8
IBM Business Process Manager - Summary
• Rich business UI with Salient Process SPARK
UI toolkit available via reseller
• Enhanced coach UI framework and tooling
leveraging SPARK technology
• Leverage the API economy via REST
integration with Open API and API Connect
• Product Insights on Bluemix (experimental)
• New Express edition, hybrid entitlement,
FedRAMP support, and configuration options
• Enhanced self-service capabilities
• Web-based Process Designer now provides
complete end-to-end authoring of process apps
• High-volume business events via enhanced
Dynamic Event Framework to enable
integration with 3rd party big data and analytics
• Automate repetitive tasks with Robotic Process
Automation
• Integrate legacy enterprise systems with no API
Low Code Development & Web Designer
Business UX
Hybrid Integration & Cognitive
BPM on Cloud
Process Analytics
Robotic Process Automation
Java 8 & Performance

Agenda
• Migration and Upgrade Definitions
• General Strategy and Improvements
• Upgrade Approaches
• Migration Approaches
• Migration Enhancements
• Top Practices
Latest Migration Deck can be found on my SlideShare account:
http://www.slideshare.net/brianmpetrini/
https://www.slideshare.net/brianmpetrini/ibm-cloud-universityidpa009ibm-bpm-upgrade-and-migration-made-easy
9

Migration and Upgrade
Definitions

Migration and Upgrade
Definitions
• Product Migration – BPM version migration, requires separate install of new BPM version,
configuration of topology and moving/migrating applications and perhaps data.
• Product Upgrade – BPM version upgrade, which is an in place fixpack on existing BPM
version. Same cell, same applications, same data.
• Topology Refactoring – Changing topology, hardware, or database, but the same BPM
product version.
• Application Versioning – Enhancing or fixing Process Apps (snapshots), updating toolkits
(libraries), or any other part of the application code.
• Process Instance Migration – After deploying a new process version (snapshot), moving
the runtime data (process state) from the older process version to the newer process version.
11

Data Ownership and responsibility
IBM
•IBM BPM product binaries, iFixes, profiles
Client
•Topology Configuration, Applications, Application Data
12

General Strategy and
Improvements

Migration Strategy & Major Enhancements
• Product Migration – Reducing frequency of migration from of every 1-2 years of product migration,
we’re aiming for 5-6 years. Federated Portal Server since 8.5.6 and federated API.
Migration checklist, interactive migration guide. Reduce risk with DB clone since 8.5.5. App-by-app
migration (services asset).
Standardized license entitlement up to 18 months.
• Product Upgrade – Every version since 8.5.0.0 has been an upgrade, including 8.6. This will
continue until v9.
• Topology Refactoring – In 8.5 we introduced topology refactoring for adding or changing hardware,
but the same BPM product version. BPM Config tool.
• Application Versioning – Design practices, Additive changes.
• Process Instance Migration – Incredible performance improvements.
14

15
Continuous Delivery
Strategy for IBM BPM
Responsive
Portal and UX
IBM BPM on
Cloud
Case & Content
Integration
Federation
Server
Process
Federation
Server
Web-based
authoring
Spring 2014
BPM 8.5.5
Spring 2013
BPM 8.5.0
Spring 2015
BPM 8.5.6
Spring 2016
BPM 8.5.7
2Q16 3Q16 4Q16
REST and
Open API

Process Federation Server
16
§ Process Federation Server enables task workers to access all their work from a single
Process Portal.
§ Tasks can be federated across
– Multiple BPM cells
– Multiple BPM releases
– BPMN and BPEL tasks
Process Federation
Server
(Liberty)
Responsive
Portal
(browser)
BPM
V8.0.1.3
BPM
V8.5.0.1
BPM
V8.5.5
BPM
V8.5.6
Responsive
Portal
(browser)
BPM
Single BPM environment
Federated environment
BPM
V8.5.7

17
Reducing the need for migration
• Upgrade strategy - Since 8.5.0, we have followed an "update only"
constraint on every new 8.5 release. This has resulted in upgrade only
infrastructure since 8.5.0 (June 2013) that will continue until we reach BPM
9. This is at least 5 years of upgrades only. Compare that to the previous
years where we forced a migration each year (every release).
• Federated API Server - In 8.5.6 we introduced a federated portal that
aggregates the information from cells of different BPM versions. This is key
to our strategy going forward as we release new versions. This way you
can let their existing applications and process instances drain from older
cells and start new processes in the new cell. This would greatly reduce the
need for application migration.

18
Migration Improvement Details
Infrastructure migration/update
In 8.5 we drastically simplified the infrastructure, improving the standardization and as a result
improved the testing coverage. We went from 9700 permutations to about an order of magnitude
fewer. Likewise we went to a central configuration file (BPMConfig).
To help with migration we have created config extraction tools that take from older versions, display
the configuration graphically for modification, and allow creation of new environments from this file.
For ifixes and fixpacks, we have been working on simplifying the ifix updates so that include the
dependency trees, making applying them simpler.
Migration checklist - we now include a migration checklist to check for the infrastructure.
DB clone - since 8.5.5 we support DB cloning for migration. This greatly reduces risk as customers
can migrate to a cloned DB and if there are any issues they can just point to the original DB.
iFix Bundle – with 8.5.6, we started bundling groups of iFixes into a single bundle that can be
installed quarterly.
Fixpack strategy - Since 8.5.0 we have been including all fixes in the next feature release. This
increases quality for our customers as we are reducing the number of code streams that we have to
support and test, allowing us to be more thorough testing.

19
Migration Improvement Details
Application migration
We have been stabilizing the programming models over the last 5 years, making fewer
changes in each release. As a result, application migration is simpler for customers
moving from later releases.
App-by-app migration [Services Asset]
In 8.5.6 we introduced a services asset the app-by-app migration for BPMN only. This will
give business more flexibility as they won't have to migrate the entire infrastructure, but
rather could focus on one or two process applications that need the latest infrastructure.
Can move SQL Server->DB2 or Oracle->DB2. Only works for 8.5.6 and 8.5.7.
Instance Migration
We continue to improve the performance of instance migration which will allow for shorter
time windows when applications are updated and older instances are migrated to the
latest snapshot. In the latest release it is an order of magnitude faster than in 8.5.6 due
to parallelism in both local threads and multiple nodes.

20
18 month entitlement
License
We recognize that the SWG standard of 90 day dual entitlement
may not suffice for large BPM deployments doing BPM Version
to Version system migrations with long running processes and in
this case have a pre-approved, 18 month extended migration
agreement that can be offered. Link to information:
http://www-01.ibm.com/software/integration/business-process-
manager/library/entitlement-migration-bpm/

WPS Upgrade & Migration Paths
From To
Version EOS Extended
EOS
BPM BPM BPM BPM BPM BPM BPM BPM
751x 800x 801x 850x 855 856 857 860
WPS 602 09/2010 09/2013
WPS 610 04/2013 04/2016 Yes
WPS 612 09/2013 09/2016 Yes
WPS 620 04/2014 04/2017 Yes Yes Yes Yes Yes Yes Yes
WPS 700 04/2015 04/2018 Yes Yes Yes Yes Yes Yes Yes Yes
migration
upgrade
For WPS 602 and 61x, we currently do not provide a direct upgrade path for runtime
migration (i.e. preserve existing process instances) to BPM 8xx. However, customers can
still use IID 8xx and manually update the applications to get it working on the latest BPM
level, and then use the “drain” approach (see later charts for details).

WLE Upgrade & Migration Paths
From To
EOS
751x 800x 801x 850x 855 856 857 860
TW 61x 09/2013 09/2016 Yes Yes Yes As
needed
As needed As needed No No
TW 62x 09/2013 09/2016 Yes Yes Yes Yes Yes Yes No No
WLE 71 09/2013 09/2016 Yes Yes Yes Yes Yes Yes Yes No
WLE 72 04/2016 04/2019 Yes Yes Yes Yes Yes Yes Yes Yes
migration
upgrade

23
Release to Release Continuity
From To
EOS
751x 800x 801x 850x 855 856 857 8.6.0
BPM 750 09/2016 09/2019 Upgrade Yes Yes Yes Yes Yes Yes Yes
BPM 751 09/2016 09/2019 Upgrade Yes Yes Yes Yes Yes Yes Yes
BPM 800 09/2017 09/2020 Upgrade Upgrade Yes Yes Yes Yes Yes
BPM 801 09/2017 09/2020 Upgrade Yes Yes Yes Yes Yes
BPM 85X 09/2019 09/2022 Upgrade Upgrade Upgrade Upgrade Upgrade
migration
upgrade

Upgrade Rules of Thumbs
1. You can use a “rolling upgrade” methodology to upgrade your BPM ecosystems.
a. In-place Rolling Upgrade
b. Side-by-side Rolling Upgrade
2. Do not upgrade your Process Center (Dev environment) until you have at least proved that the
upgrade is working in your QA environment.
3. The version of Process Designer and Integration Designer must match the version of the Process
Center.
4. The version of Process Center and Process Server must match in order for the Process Server to
be connected as “online”.
5. An application that you developed using an older version of the BPM product can be deployed to
run on a newer version of BPM as long as it is not using features that have been removed.
6. We strive to maintain API compatibility in BPM mod and fixpack releases.
7. In BPM 85xx, we enabled the support of online rolling upgrade:
a. BPM 8500 Process Designer and Integration Designer to connect to BPM 8501 of Process
Center and Process Server (for debugging).
b. A BPM 8501 Process Server can connect as “online” mode to BPM 8500 Process Center.
c. The purpose to facilitate debugging of upgraded application and allow a more gradual roll
out of the upgrades.

Process – In-Place Rolling Upgrade
start
Certify PS
<Test> end
Certify PS
<Staging>
Certify PS
<Prod>
Certify PC
In this procedure, we will upgrade PS first.. From <Test> to <Prod>, and finally upgrade PC.
Pros:
1.Upgrade and certify one Process Server environment at a time in an orderly fashion.
2.Upgrade PC last as we want to ensure we can continue to provide fixes to PS running at current
version.
Cons:
1.Upgrade PC last means developers cannot utilize new features until the entire eco-system is
upgraded.
2.With the exception of 8501, any other upgrade would force the PS to go offline to the down-level PC,
thus requiring offline deployment until the PC is upgraded.
We should always take a full backup of your environment before the upgrade, this allows up to restore
any environment during this period in order to deliver a hot-fix of your application to your <Prod>
environment before your <Prod> environment can be upgraded.

Process – Side-by-Side Rolling Upgrade
start
Side-by-side
“upgraded”
PC
Certify and
Re-target PS
<Test>
Certify and
Re-target PS
<Staging>
Certify PS
<Prod>
In this procedure, we will setup a new “upgraded” PC side-by-side, and then proceed to upgrade each of the PS
environment.
Pros:
1.An “upgraded” PC is available immediately for new development and tests
2.Customers can certify new product version on a per-application basis without impacting existing development and
test.
3.All Process Server environments can maintain “online” status all the time.
Cons:
1.Setup a side-by-side “upgraded” PC will require additional IT resources and may incur additional licensing cost.
2.May require more work if the customers’ configuration is not well documented.
3.Depending on the approach to setup the side-by-side PC, one will lose existing “playback” instances data.
Sunset
old PC end

Managing fixpack upgrade downtime
By performing some upgrade tasks in parallel, we can reduce the time it took
to upgrade. In this example, we are upgrading to 7.5.1.2.
Upgrade from 7.5.1.x to 7.5.1.2 Time
• update Installation Manager
• backup configuration
1 – 2 min
(in parallel)
• update Deployment Manager and Nodes
using a “staggering” approach with 10 min
delay between each node.
60 min
• upgrade clusters
• upgrade database
10 min
Total 72 min*
•Time is taken based on a test system with 3
nodes. The actual time will depend on a number of
factors such as disk access time, network latency,
CPU speed, etc.
• For upgrade from 7.5.0.0, you can expect more
time is needed for updating the individual node.

Engage IBM EAS and ISSW for a migration assessment and assistant
Plan your migration
30
Plan your migration
1. Understand Your
Reqts and Environment
2. Migration
Assessment
Team Regular Communication
3. Identify Project Team
and Project Plan
4. Develop Migration
Strategy and Documents
7. Test Migration and
Recovery Plan
5. Migration and Test
Your Applications
6. Clean up
Source Environment
8. Go Live Planning
and Execution

Landscape
1- Current product version used to
support existing production
applications
Current
Process Server
(Test/ Staging/
Production)
Current
Process Center
2- New applications are developed on new
version.
New Dev
Process Server
New
Process Center
New Process Server
(Test/Staging/Production)
1
2
4
3
3- Export/import Toolkit for
refactoring
4- Migrate artifacts and/or business data
5- Deploy new and
migrated apps
5

Migration Approach
Drain - Application migration and “drain” existing instances
• Let existing instances in V-old run to completion, start new instances in V-new
system.
Runtime Migration - Application migration followed by Runtime migration
• Once ALL applications are working in V-new, convert the existing database to
make it compatible with V-new in one shot.
Milestone Transfer - Transfer process state mid-stream using custom logic to
new version.
• A variation of the “Drain” approach.
• Let existing instances in V-old run to a designated set of business milestones,
start new instances in V-new system from those milestones.

What to Migrate?
Pros Cons
Artifacts Only
Migration
(Drain or
Milestone
Transfer)
Start with a clean database. Leave messy
data behind.
Parallel production environment allows for
app-by-app migration and no production
downtime.
Process history are not transferred to the
new system.
Parallel production environment requires
additional maintenance and resources.
Business Data
and Applications
Migration
(Runtime
Migration)
Source environment applications and data
are migrated to the target environment.
Process and human tasks can start in the
source environment and complete in the
target environment.
Bringing over all data depending on size
and complexity can increase migration
risks which requires additional testing.
Downtime required. All applications must
be ready before you can start migrating
the system.

Process Center Migration
Observing that Process Center contains “playback” instances only, there is really no
business needs to migrate “playback” instances to the new product version. Based on this
assumption, we are simplifying the Process Center migration to application-only migration.
• Setup a new PC target environment with new database.
• Migrate individual application artifact by exporting “active” snapshots from source
environment to target environment in chronological order.
• Runtime data (instances, tasks, tracking groups, etc) and offline server deployment
information will not be migrated.
Advantages:
• One can setup Process Center right away and start working on application migration.
• Application can be moved to new product version one application at a time.
• Existing V-old Process Center is still available to handle fixes for production system.
• No downtime for Process Center.
Not applicable if
Process Center is not
used in your system.

BPM 8.5.5/8.5.6/8.5.7/8.6 Migration Enhancements
Improve migration robustness, ease-of-use and planning
• Revised documentation with enhanced interactive migration guide and guidance on migration methodology to better guide
customers and services on how to plan their migration project.
• Migration Pre-Validation Tool + Post-Validation Health Center
• Pre-check and report migration potential failures
• Save cost of migration late phase failure, recovery and redo
• Post-Validation via BPM Health Center, speed up target environment health check
• Easier environment setup via Configuration Migration Tool
• Migration paths support with a target environment that is set up with about 400 source-environment basic properties around
database, security, and the most important performance parameters to the client’s environment.
• Reduce about 50% post-migration actions on properties
• Separate tool can export/import WAS application level configurations which are not owned by the BPM, like: data source,
auth-alias, SSL settings
Speeding up migration
• Quicker migration via multi-thread enablement
• Migration from BPM v7.5.1 migration shows 2x ~ 3x improvements
• Migration from TW v6.2 migration can see up to 20x improvements
36

Interactive Migration Guide
• Help you determine the expected document that matches your migration
scenario, save your effort to search infocenter and navigate between
different topics.
37
Two steps wizard

Validate source environment before migration
• We introduced migration pre-validation tool to help you find potential
issues before real migration, and what you should take care during
migration
• Validate current environment to make sure it’s ready to do migration
• Read required information that will be used in latter migration steps
• Show error if it’ll block migration, or the source environment isn’t in the
expected status
• Show warning if you need to take care before or after migration
• Show warning if there is some big number of data will have performance
impact during migration
38

• Report sample 1 for migration prevalidation
39

• Report sample 2 for migration prevalidation
40

Understand configuration migration
• Source environment information
• Map to the supported target based on what your source environment was.
• Make sure it’ll reuse old database on the target.
• Security
• Federated LDAP
• LTPA
• File registry
• Performance tuning
• Customized XML files (e.g. 100Custom.xml)
• Some properties will be moved to WCCM
• Keep remaining customization and copy to each node on the target
• Business Process Choreographer
• Business Flow Manager
• Human Task Manager
41

Understand configuration migration
42
Source Target
Move configuration
Edit the exported properties
file using Configuration
Editor
BPMConfig -migrate BPMConfig -create
• WebSphere Process Server 6.2.x or 7.0.0.x
• WebSphere Lombardi Edition 7.1 or 7.2
• IBM Business Process Manager 7.5.x or 8.0.x or 8.5.X
Express/Standard/Advanced
• IBM Business Process
Manager 8.5.6 or higher
Express/Standard/Advanced
/AdvancedOnly

Understand database upgrade
• For Standard database: Process Server and PDW database
• DBUpgrade will cover both schema update and data transform
• Tune the script to get better performance (thread or batch size)
• For Advanced database: Common/BPC/BusinessSpace
• upgradeSchemaAll will run all required upgrade SQL files
• upgradeSchemaAll will also run the initialization SQL for newly added
capability if any
• Support to test and validate migration using cloned database
• BPMMigrate will update the topology information in the database
• Import SIB messages to the target
• Recreate WAS scheduler tasks
43

Understand database upgrade
44
Do other configuration
customization
Estimate migration
window
...
Source
Target
Cloned
Target
Cloned Cloned
Clone database
BPMConfig –update -dataSource
Test database upgrade using cloned
database, and finally retarget your
current environment to the original
database to do the last run.
Test migration against
cloned databases

Understand
database
upgrade
• Performance improvement on database
upgrade
• DBUpgrade have much performance improvement, and
you can add more threads to handle the transform of
large number of instance and task
45
Wang Lei ok, thanks 4:53:22
PM

Cleaning up before migration
The more data we have in the BPM system, the longer it will take migration to run.
So it is important that before we run migration, remove information that are not
required anymore in the new system.
• ProcessInstancesCleanup command to remove “completed” process instances.
• Performance Data Warehouse prune command for removing PDW data.
• BPMDeleteDurableMessages command to remove durable events that are no
longer needed.
46

BPM Health Center
• Check the health status of the deployment environment after migration,
should be the first step to validate migrated environment before other
planned testing
47

App-by-App (IBM Lab Services Asset) for BPM
Standard – 8.5.6 and 8.5.7 only.
Support selective migration of applications runtime data
1. Selective migration
1. Only move certain applications
2. Only move the data which need keep in the new environment by the time range
3. Only move the system data like users, groups, user-group-relationship, user attributes, etc
2. Splitting of deployment systems
1. Refine the deployment design
2. Scaling out application
3. Database vendor conversion - other databases move to DB2
What this is not intended for:
1.Temporary move of applications for the isolation and then moved back
2.Massive restructuring of the BPM environments
3.Move applications freely among different BPM environments
4.Move advanced data (BPEL)
48

App-by-App compare with runtime migration
Pros Cons
App-by-app
Migration
1. Migrate one BPM Standard application at a time
to the new system to reduce migration risk.
2. Support database conversion to DB/2 from
Oracle or SQL Server.
3. Support limited migration undo.
4. Enhanced Pre-validation before migration.
5. Minimum system downtime (restart target
system after migration, stop event manager
during migration)
1. Support BPM Standard only. Advanced content
is not migrated.
2. DB2 for z/OS databases are not supported.
3. Available as Services Asset only at this point.
Business Data
and Applications
Migration
(Runtime
Migration)
1. Support both BPM Standard and BPM
Advanced.
2. Source environment applications and data are
migrated to the target environment.
3. All historical information is preserved
1. Bringing over all data depending on size and
complexity can increase migration risks which
requires additional testing.
2. Full Downtime required. All applications must be
ready before you can start migrating the system.

IBM Cloud Services Migration Project Roadmap
Goal:
• To provide a high-level
understanding of migration options;
• Capture the information that is
relevant to the migration
• Recommend next steps.
Steps:
• Review current infrastructure &
project goal
Input:
• Migration Discovery Questionnaire
Output:
• A documented understanding of the
current infrastructure; a
commitment by the client to invest
their time in a Migration
Assessment/Pilot
Goal:
• To provide ROM estimates for
migrating selected process
applications and service
integrations in a ‘like for like’
fashion from the current
environment to the target
environment
Steps:
• Process Application business and
functional review
• Process App. architectural review
• Process App. source code review
Output:
• High level migration approach
• ROM estimation
Goal:
• To migrate selected process
applications and service
integrations from the current to
target environment
Steps:
• Install and configure selected
environments and tools
• Migrate code to the new
environment
• Perform testing & defect
resolution
Output:
• Migrated applications and
environment
• Team enabled
Discovery Call
Duration: 2 hours
Discovery Workshop
Duration: 1 to 2 days
No charge
Implementation
Duration: varies, depending on scope
and complexity

Questionnaire: 30 questions to discover the potential scope
• Version
• Runtime
• Application
• Operational model
• Test
• Converged with WAS
migration questionnaire
52

Migration Workshop
Goals Review the migration baseline Define application and asset inventory.
Identify customizations
Review current physical architecture
Assess Hardware / Software requirements
Review deployment strategy
Define migration validation strategy
Define migration approach Determine runtime migration approach
Recommend solution architecture.
Recommend BPM topology
Identify key improvement opportunities enabled by new/enhanced
product features.
Define staffing skills needed
Determine next steps Workshop report with recommendations and findings
Rough Order Of Magnitude estimate and project approach (WBS)
Define the best migration approach
Who IBM Migration Specialist
<IBM BPM Developer>
IBM Client Partner
IT Architect
BPM Developer
Project manager
Format 1 to 2 days No charge
53

Top Practices for Successful Migration
• Minimize Refactoring – we are often tempted to make significant changes
to the applications as part of a migration project. This can lead to un-
intended delay in projects or make it impossible to migrate runtime data.
• Having a comprehensive regression test plan, including non-functional
tests such as stress and performance tests, can help eliminate surprises in
the project.
• Review and playback often and regularly with business and IT stake
holders, this avoids last minute surprises such as user experience
expectation, security concerns, etc.
• Use good quality data for in-flight migration testing (UAT or production
databases). Database from development environment contains a lot of
development “noise” which causes problems
54

Top Practices for Successful Migration
• Test database upgrade using cloned database of production environment,
estimate migration windows and verify the migrated environment
• Carefully test migrated instances for each Application. Some problems can be
revealed only with specific development patterns unique to specific process
application (e.g. serialization changes between TW6 and BPM8 affected event
correlation)
• There is no fixed formula to estimate the time up front as the migration depends
on a number of factors such as number of process instances, tasks, users, groups,
durable subscriptions, tracking groups, size of your data and execution context,
etc.
• Applications should be upgraded and running correctly in target
system at least 2 months before go-live date. Migration and Performance
testing should start as soon as possible, not just a couple weeks before go-
live.
55

Other special considerations
• Account of changes in security model early – want to switch to LDAP
from file-based repository?
• Account for non-standard cluster configuration if you’re not following
the IBM recommended golden topology for your setup.
• BPM + Monitor. If your source BPM environment is augmented with
Monitor in the same cell, but in BPM 8550/8560/8570, we don’t support
BPM and Monitor in the same cell any longer, you have to follow two
separate procedures to migrate BPM and Monitor to separate cells on
BPM 8550/BPM 8560/BPM 8570.
56

Other special considerations
• Test the cases that some instance arrives at an activity that waiting for
some event (UCA), make sure the messages can still be consumed after
migration.
• If you’re migrating from multiple deployment environments, you need to do
the migration procedure for each of your deployment environment.
• Port number maybe changed after migration, you need to update them
manually or use the new ports.
• BPMMigrate command can rerun if it doesn’t import SIB messages yet or
you can clean SIB tables before the second run.
• Backup fileRegistry.xml if you want to enable LDAP after migration, or will
meet with some errors when try to access the document tables.
• We don’t support the migration of IID UTE
57

Other considerations
• SOE & Browser version, e.g. BPM 856 add supports for IE11.
• Test web UI for browser compatibility, esp. any pages with customized CSS, customized
web page with HTML elements, uses 3rd party javascript libraries (e.g. jQuery), or using
browser objects.
• Process Portal: the built-in Portal is updated in 856 but we do not expect any
compatibility issues.
• If moving from BPM 8013, BPM 856 is just an updated portal and we do not expect any
compatibility issues.
• If moving from BPM 751, BPM 856 is an updated portal from BPM 8013 with similar user
experience.
• If you have a customized Portal, and you’re only using documented BPM API, then the
customized Portal should continue to work in BPM 856.
• Heritage Coaches
• There is no major changes to Heritage Coaches from BPM 751x/801x to BPM 8.5.6. We
do not expect any compatibility issues.
58

Other considerations
• Dojo version
• Dojo is an open source standard to build web UI.
• Different BPM versions ship with different Dojo version:
• Dojo 1.6.1 in BPM 7511
• Dojo 1.7.4 in BPM 8013
• Dojo 1.10.3 in BPM 856
• If Dojo is used to build custom web UI, Please refer to release notes to determine if
changes are necessary.
• https://dojotoolkit.org/reference-guide/1.8/releasenotes/1.8.html
59

Other Considerations
• Coach NG (available in BPM 8013) is build using Dojo
• If your applications only uses the built-in Coach Views, we do not expect any compatibility issues.
• If you develop your own custom Coach Views and use dojo:
• If application continues to use 8013 Coach Toolkit, dojo version will remain the same as before and we do
not expect any compatibility issues.
• If applications updates to use 856 Coach Toolkit to take advantages of new features, the dojo version will be
updated from dojo 1.7.4 to dojo 1.10.3.
• As a good practice, minimize your direct dependency on dojo by centralizing all your dojo code to
a small set of “base” Coach Views, and then build more complex Coach Views on top of those.
• Guidance on System toolkit upgrade
• Before making any function enhancements to your applications, make sure your application
works with the old System toolkit
• Once validated, upgrade to the latest System toolkit to take advantages of the updated features.
60

Migration References
• Planning a migration to the latest version of IBM BPM and IBM
Business Monitor
http://www.ibm.com/developerworks/bpm/library/techarticles/1502_sharma/1502_sharma
.html
• Estimating the efforts for IBM Business Process Manager migrations –
why it’s not easy!
https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/bpmmigrationsi
zing?lang=en
61

IBM® Business Process Manager Early Design Program
What is the IBM BPM EDP Program?
ü Offers a variety of early programs to our clients from design feedback sessions
to education on pre-released product offerings.
ü Provides discussion on unreleased or future development on select IBM
products.
ü Easiest and most valuable way for our clients to influence IBM development
and product direction with their feedback and participation.
ü Provides direct access to BPM subject matter experts and early education
materials to clients on IBM BPM product and key capabilities.
How do I sign up?
• Contact your IBM Account Team about participating in IBM BPM Early
Programs
• Contact us directly at bpmep@us.ibm.com
Website:
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere.shtml

IBM Cloud University 2017 | October64
Types for data for backup
• Installation Data
• Includes the product binaries, ifixes, and profiles
• Backups should be taken after any new of product software has been installed.
• Purpose: Since assuming the fix level is known, the binaries could be re-installed from the product media, the
benefits of this backup are for faster creation of binaries, and assurance that you can restore the exact same set
of binaries.
• Topology Configuration Data
• Includes all configuration done over and above the base creation. Federating nodes, creation of containers,
configuring product base data sources, creating of product related data schemas in databases.
• Purpose: Since all of these actions can be scripted in a fully automated install, the benefits of backup are to
improve the time taken to create the environment, and also to be able to create a genuine replica of the original
cell, including an system generate unique ids associated with it.
• Application Configuration Data
• Includes all deployed applications, and any associated application specific changes made to the environment.
• Purpose: Since all executable deployed to the environment should be stored in version control it should
therefore be possible to re-deploy all applications onto clean topology. There may be some benefit in the
comparative time to restore compared to creation of an environment from scratch and deployment of
applications. There may also be an advantage in diagnosis of issues requiring comparative analysis of the
application versions deployed.
• Runtime Data
• Runtime data is defined as data that represents the current state of interaction occurring in WPS at a given time,
and typically contains the current state of the business data passing through the system. Runtime data exists in
the databases, messaging engine destinations (ultimately backed by a database), and in the transaction logs.
Remember, two phase commit transactions might be taking place in the infrastructure, so anything less then a
synchronised backup will be pointless.

Countless capabilities
HYBRID CLOUD
IMPLEMENTATION
CLOUD & DATA
DESIGN
IDENTIFY
OPPORTUNITIES
DIRECTION &
SCOPE
BUSINESS
CASE
OPERATIONAL
MANAGEMENT
FRAMEWORK
GOVERNANCE &
ORGANZATION MODEL
CLOUD
TECHNICAL
SUPPORT
CLOUD NATIVE
SOLUTION
TRANSITION
WORKLOADS
UNLOCK DATAMANAGED
APPS
IBM Cloud
Professional
Services
IBM
Bluemix
Garage
IBM
Analytics
Services
3 practices
Services
immersed in
startup DNA
and the newest
technologies
Cloud Advisory
Services and
integrated
solutions for
hybrid cloud
Analytics-
based solutions
that empower
your data
5 principles
1. METHODOLOGY & ASSETS
We provide the most potent hybrid cloud
methodology and assets available.
2. DEEP SKILLS
We curate the most agile, deeply-skilled
expert teams in the industry.
3. FAST SUCCESS
We champion prescriptive, guided cloud
adoption journeys with adaptable
blueprints.
4. CONFIDENCE
We enable transformations by empowering
our clients.
5. WORLD-CLASS SUPPORT
We deliver world-class support to make
sure you succeed.
It’s not just about building a cloud infrastructure –
it’s about strategically adopting cloud to realize its benefits
Stop by the Services Booth in the expo
to talk about how we can help

Notices and disclaimers
Copyright © 2017 by International Business Machines Corporation (IBM).
No part of this document may be reproduced or transmitted in any form
without written permission from IBM.
U.S. Government Users Restricted Rights — use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to
products that have not yet been announced by IBM) has been reviewed
for accuracy as of the date of initial publication and could include
unintentional technical or typographical errors. IBM shall have no
responsibility to update this information. This document is distributed
“as is” without any warranty, either express or implied. In no event
shall IBM be liable for any damage arising from the use of this
information, including but not limited to, loss of data, business
interruption, loss of profit or loss of opportunity. IBM products and
services are warranted according to the terms and conditions of the
agreements under which they are provided.
IBM products are manufactured from new parts or new and used parts.
In some cases, a product may not be new and may have been previously
installed. Regardless, our warranty terms apply.”
Any statements regarding IBM's future direction, intent or product
plans are subject to change or withdrawal without notice.
Performance data contained herein was generally obtained in a
controlled, isolated environments. Customer examples are presented
as illustrations of how those customers have used IBM products and
the results they may have achieved. Actual performance, cost, savings or
other results in other operating environments may vary.
References in this document to IBM products, programs, or services
does not imply that IBM intends to make such products, programs or
services available in all countries in which IBM operates or does
business.
Workshops, sessions and associated materials may have been prepared
by independent session speakers, and do not necessarily reflect the
views of IBM. All materials and discussions are provided for informational
purposes only, and are neither intended to, nor shall constitute legal or
other guidance or advice to any individual participant or their specific
situation.
It is the customer’s responsibility to insure its own compliance with legal
requirements and to obtain advice of competent legal counsel as to
the identification and interpretation of any relevant laws and regulatory
requirements that may affect the customer’s business and any actions
the customer may need to take to comply with such laws. IBM does not
provide legal advice or represent or warrant that its services or products
will ensure that the customer is in compliance with any law.

Notices and disclaimers
continued
Information concerning non-IBM products was obtained from the
suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products in
connection with this publication and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be
addressed to the suppliers of those products. IBM does not warrant the
quality of any third-party products, or the ability of any such third-party
products to interoperate with IBM’s products. IBM expressly
disclaims all warranties, expressed or implied, including but not
limited to, the implied warranties of merchantability and fitness
for a particular, purpose.
The provision of the information contained herein is not intended to,
and does not, grant any right or license under any IBM patents,
copyrights, trademarks or other intellectual property right.
IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS,
Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document
Management System™, FASP®, FileNet®, Global Business Services®,
Global Technology Services®, IBM ExperienceOne™, IBM
SmartCloud®, IBM Social Business®, Information on Demand, ILOG,
Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON,
OpenPower, PureAnalytics™, PureApplication®, pureCluster™,
PureCoverage®, PureData®, PureExperience®, PureFlex®,
pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®,
Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®,
StoredIQ, Tealeaf®, Tivoli® Trusteer®, Unica®, urban{code}®, Watson,
WebSphere®, Worklight®, X-Force® and System z® Z/OS, are
trademarks of International Business Machines Corporation, registered
in many jurisdictions worldwide. Other product and service names
might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the Web at "Copyright and trademark
information" at: www.ibm.com/legal/copytrade.shtml.

IBM Cloud University 2017-IDPA009-IBM BPM Upgrade and Migration Made Easy

IBM Cloud University 2017-IDPA009-IBM BPM Upgrade and Migration Made Easy

More Related Content

Similar to IBM Cloud University 2017-IDPA009-IBM BPM Upgrade and Migration Made Easy (20)

More from Brian Petrini (10)

Recently uploaded (20)

IBM Cloud University 2017-IDPA009-IBM BPM Upgrade and Migration Made Easy