Proper planning and following some of the top practices are key to ensure a successful upgrade and migration of BPM system. In this session, we will talk about how to plan an easier and quicker migration, including a comprehensive consideration and plan based on your source environment, validations before migration, handle special requirements when move to a very different target environment, estimate your migration window and evaluate the business impact, plan your tests on regression and new features etc. Also we will introduce migration utility key improvements in BPM v8.5.x which can significantly reduce your migration failure, downtime and post-migration actions.

1. © 2015 IBM Corporation
0
Best Practices: BPM Implementation,
Migration and Upgrade
Allen Chan, IBM BPM Lead Architect – Install, Config and Migration
Brian Petrini, IBM BPM Technical Product Manager
Jerome Boyer, IBM Software Services, Implementation Methods

2. Agenda
• BPM 8.5.6
• Upgrade Approches
• Migration Approches
• Top Practices
1

3. Act in context with data Drive simplicity and
speed with cloud
Accelerate customer
engagement
Highlights of
What’s New in Business Process Manager v8.5.6 & Business Monitor
§ Watson integration
samples
§ Embedded content
store
§ Embedded rules
Product Foundation
§ BPM Developer Center
§ Federated Portal
• Seamlessly blend tasks from
multipleBPM servers across
versions (v8.0+)
§ Asset to Isolate Process
Applications (start, stop,
move)
§ Business Monitor updates
§ IBM PureApplication®System
pattern released
§ Expanded operating system
coverage
§ Dashboard customization with
Rapidly Adaptive Visualization
Engine
§ BPM on Cloud
• Tiered Pricing
• Data center supportin
Japan and Hong Kong
§ Workflow Service on
Bluemix
§ Mobile Responsive
Portal
§ Case Management
• Case Linking
§ Enhanced FileNet
Content Manager
support
§ Responsive Coaches
§ Click to create
Worklight projects
§ REST API for custom
mobile application
development
Key: New feature Previously released feature

4. WPS Upgrade & Migration Paths
From To
Version EOS BPM BPM BPM BPM BPM BPM
751x 800x 801x 850x 855 856
WPS 602 09/2010
WPS 610 04/2013 Yes
WPS 612 09/2013 Yes
WPS 620 04/2014 Yes Yes Yes Yes Yes Yes
WPS 700 04/2015 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).

5. WLE Upgrade & Migration Paths
From To
Version EOS BPM BPM BPM BPM BPM BPM
751x 800x 801x 850x 855 856
TW 61x 09/2013 Yes Yes Yes As
needed
As
needed
As
needed
TW 62x 09/2013 Yes Yes Yes Yes Yes Yes
WLE 71 09/2013 Yes Yes Yes Yes Yes Yes
WLE 72 04/2016 Yes Yes Yes Yes Yes Yes
migration
upgrade

6. BPM Upgrade & Migration Paths
From To
Version EOS BPM BPM BPM BPM BPM BPM
751x 800x 801x 850x 855 856
BPM 750 09/2016
expected
Upgrade Yes Yes Yes Yes Yes
BPM 751 09/2016
expected
Upgrade Yes Yes Yes Yes Yes
BPM 800 09/2017
expected
Upgrade Upgrade Yes Yes Yes
BPM 801 09/2017
expected
Upgrade Yes Yes Yes
BPM 850 n/a Upgrade Upgrade Upgrade
migration
upgrade

7. 6
Migration Improvements
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.
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.

8. 7
Migration Improvements
Application migration
We have been stabilizing the programming models over the last 4 years, making fewer
changes in each release. As a result, application migration is simpler for customers
moving from later releases.
App-­by-­app migration
In 8.5.6 we will introduce as a services asset the app-­by-­app migration. 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.
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.

9. 8
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/

10. 9
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 3 years of
upgrades only. Compare that to the previous years where we
forced a migration each year (every release).
• Federated API/Portal -­ In 8.5.6 we are introducing 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.

11. Upgrade Approaches
10

12. 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.

13. 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 (Fuji), 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.

14. 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 enviroment.
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

15. 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.

16. Migration Approaches
15

17. Engage IBM EAS and ISSW for a migration assessment and assistant
Plan your migration
16
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

18. 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

19. 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.
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.
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.

20. 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.

21. 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.

22. Migration Enhancement
21

23. BPM 8.5.5/8.5.6 Migration Enhancement
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
22

24. 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.
23
Two steps wizard

25. 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
24

26. Validate source environment before migration
• Report sample 1 for migration prevalidation
25

27. Validate source environment before migration
• Report sample 2 for migration prevalidation
26

28. 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
27

29. Understand configuration migration
28
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
Express/Standard/Advanced
• IBM Business Process
Manager 8.5.6.0
Express/Standard/Advanced
/AdvancedOnly

30. 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
29

31. Understand database upgrade
30
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

32. 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
31
Wang Lei ok, thanks 4:53:22
PM

33. 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.
32

34. 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
33

35. App-­by-­App services asset for BPM Standard
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)
34

36. 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.

37. Migration Top Practices
36

38. IBM 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

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

40. 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
39

41. 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
40

42. 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.
41

43. 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, 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.
42

44. 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
43

45. Additional In-­depth BPM Sessions
• 1931 IBM BPM Upgrade and Migration Roundtable – in Coral C
• Tue 9:30-­10:30,
• Wed 17:30-­18:30,
• Thu 10:30-­11:30
44

46. Meet other clients and learn about Expert
Access Services for on-­demand
enablement and consulting on
development, migration and infrastructure
topics.
Wednesday, February 25, 2PM-­3PM
Jasmine H, floor 3, Mandalay Bay
Please RSVP to La Donna Quinn – lquinn@us.ibm.com
Please show this invitation on your Smartphone at the reception entrance, or print and
bring with you to gain entrance.

47. Migration References
• Planning a migration to the latest version of IBM BPM and
IBM Business Monitor
http://www.ibm.com/developerworks/bpm/library/techarticles/15
02_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/aimsupp
ort/entry/bpmmigrationsizing?lang=en
46

48. Questions?

49. Notices and Disclaimers
Copyright © 2015 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.
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.

50. Notices and Disclaimers (con’t)
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, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document
Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand, ILOG,
Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®,
pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®,
QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®, 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.

51. Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee
Portal to complete your session
surveys from your smartphone,
laptop or conference kiosk.