Migrating & upgrading connections can be a daunting - Here i share some trips, best practises and information on how to ensure that your upgrades are stress free

1. Toronto, June 6-7 2016
Connections Migration
the easy way
Sharon Bellamy James
Rock Team

2. Who am I?
Sharon Bellamy James
• Rock Team
• IBM WebSphere since 1999
• IBM Connections since version 2 / 2008
• Many years of experience in:
• Migrations
• Administration and installs
• Integration/Customization
• DOCUMENTATION
• Tiny bit of a Starwars and Disney fan
• Charity fundraising Cosplayer/Costumer

3. Agenda
• Plan
• Gather your requirements
• Check system reqs
• Get the right software
• Test system first
• If you don’t have one – build
one
• Side by side where
possible
• Backup your data
• Keep it simple
• Upgrade first
• Test
• Add additional components
• Test again
• Do not use all or nothing
• Can cause issues
• Difficult to debug
• Troubleshooting

4. But remember ……

5. What do you need to know?
• Essentially its like installing a new Connections system
• There is no magical upgrade button
• Most components need updating or are new versions
• Sometimes the instructions for configuring have completely
changed
• Know what to back up
• Read the migration guide
• Backup the shared data, customizations and Data Bases before you
start
• DO NOT just copy the customizations over
• Often jsps or config has changed. Once new version is installed –
reapply the changes in the new file versions
• READ THE DOCUMENTATION – before you do anything

6. Toronto, June 6-7 2016
Gather requirements & get the
right software
PLAN

7. Gather requirements
• Regularly check requirement documents
• All versions are listed here:
• http://www-01.ibm.com/support/docview.wss?uid=swg27012786
• Check all notes, Download PDF
• Be careful with installation documents
• Sometimes wrong dependencies mentioned
• Supported statement does not mean
it’s licensed
Connections 5.0 CR3
Connections 5.5

8. Download the right software
• Check the system requirements
• Make a list
• Get the correct versions
• WAS is mutli os, as are the
fixes
• Connections– os versions
• TDI – os versions
• DB2 – os versions (win 2012
requires 10.5 fp 5 or above)
• Other DBs – use supported
versions – or you may hit
issues
• Install a DB Client
• Install 64 bit where possible
• Install an LDAP browser
• *Real* text editor – notepad
is useless
• Fiddler for support & its
useful
• If Windows use a tool like
baretail for watching logs

9. Toronto, June 6-7 2016
Test system first:
Not got one? Build one!
TEST

10. No Test System? Build One
• ALWAYS test a migration – did I mention ALWAYS!!
• A test or dev system is always a good idea
• Useful for migrations, fix packs, customization and config
changes
• Doesn’t have to be a mirror of live – can be a single node system
• VM or spare machine under a desk – it will do
• Same OS, DB, LDAP and HTTP server a must for sensible
testing
• Ensure your boss, project manager etc. knows how
important a test system is
• Add a test system to the requirements

11. Toronto, June 6-7 2016
Pros and Cons:
Side by Side vs In Place
Side by Side vs In Place

12. Side by Side vs In Place
Side by Side
• Completely separate environment –
live system can stay up whilst
migration testing / system building
occurs
• Allows for full testing before go-live
• Any changes can be made to the new
system with little pressure as the live is
still functioning
• An actual live migration can be run
when the system has planned
downtime (weekend, maintenance
window etc) – can take as little as 4
hours (depending on amount of data)
• If issues with live migration – existing
system is still available to roll back to
in seconds
• Less risk, less pressure, easier to
debug
In Place
• There is NO TEST – all or nothing
• Once you have started there is no real
roll back
• System is down when the migration
takes place – users are off for however
long it takes
• Much pressure if there is a problem
• Avoid where possible
• If there HAS to be an in place
migration ensure sufficient offline
backups and snapshots have been
taken to allow a restore
• Have a plan to roll back, where
possible migrate when system has
down time (weekend, maintenance
window etc)

13. Side by Side vs In Place – install/test
Side by Side
• Stop the Connections system –
back up everything
• If a test migration - Restart and let
your users carry on
• Install a fresh Connections system
elsewhere and configure it up as
per normal – apply fixes,
customizations etc.
• Test the clean system to ensure it
works as expected – then BACK
IT UP
• Migrate the data – File system
(Connections data shared)
• Migrate the DB’s – either with the
DBT or drop, restore and update
• Test
In Place – there is no test
• Stop EVERYTHING – your system
will be completely offline whilst the
update takes place
• Back it up : DBs and File System
• Uninstall Connections
• Ensure WAS profiles are clean (no
apps or config), update
WebSphere, recreate and
configure (as per install)
• Install connections and configure
• Drop new Connections DBS,
restore and update existing
• Configure connections, apply
fixes, any customizations
• Test

14. Toronto, June 6-7 2016
Back up the correct data
Back up

15. Backing up for Migration
• Shared File System
• Back up the whole of the
shared content store
• We can restore a subset
shared_content_store/audit
shared_content_store/activities/content
shared_content_store/activities/statistics
shared_content_store/blogs/upload
shared_content_store/communities/statistics
shared_content_store/customization*
shared_content_store/dogear/favorite
shared_content_store/files/upload
shared_content_store/forums/content
shared_content_store/profiles/statistics
shared_content_store/wikis/upload
• Data bases
• ALL OF THEM!!
• Even if you are using the
Database transfer tool
(DBT)
* We refer to this not restore the whole folder

16. Toronto, June 6-7 2016
Migration – Keep it simple
The Migration

17. Keeping the migration simple
• NEVER (seriously NEVER) do an in
place migration
• Side by Side allows to test a clean
system before running the data
migration
• Use the same DB type (i.e DB2 to
DB2)
• Install with example.com for mail
notifications
• Run at least one test data migration
• Test all customisations with migrated
data
• Document everything – record for go
live and subsequent upgrades
• If an issue occurs fix it – don’t plough
on regardless
• If you have to do an in place DB
migration make sure DBA understands
the steps and order things need to be
run
• Firewalls / DNS / Network – get these
sorted before you start.
• Dedicated *Admin* user for install
• Simpler to implement phases to
minimise risk – allows testing at each
stage
• Test without proxies – add once
working – Keep it simple to install

18. Toronto, June 6-7 2016
Don’t fall for all or nothing
Keep It Simple Stupid – PHASED Migration

19. Phase migration and additional builds
• Build new system & configure
it as live - TEST
• Migrate Data - TEST
• Add Customizations – TEST
• Cognos Metrics/Kudos – TEST
• Connections Content Manager
(CCM) – TEST
• IBM Docs / File Viewer – TEST
• Additional integration - TEST
• Testing each phase is simpler
to debug and resolve issues –
Support will thank you for it
• PLAN!! Gather the system
requirements then phase out
where possible
• All or Nothing can cause
stress, downtime, many PMRs
if there are multiple issues
• Explain to the project manager
the reasoning behind phased -
it may looks like it will take
longer to deploy – often
doesn’t

20. Phase migration and additional builds
• All or Nothing
• What happens when you
try to do too much at the
same time
• Issues with Cognos, Issues
with CCM, Issues with
Docs, Issues with data
migration
• Issues were fixed,
something else broke
• Hard to debug as too much
going on at any one time.No quick wins, customer loses focus, many
PMRS opened, hard to resolve issues as
multiple products with problems.

21. Phase migration and additional builds
• Phased
• Connections upgrade from 4
to 5
• Deployed FIB for surveys, add
the additional customization
• Deployed Cognos / Kudos for
metrics
• Connections Content Manager
• Then last but not least IBM
Docs
Quick wins, customer has working V5 system,
easy to debug any issues as only with one of the
components.

22. Toronto, June 6-7 2016
Post migration and troubleshooting
Troubleshooting

23. Post migration steps & trouble shooting
• DO NOT SKIP
• Read the knowledgebase
tasks
• Clear task schedulers
• Rebuild search index
• Synchronize files shared
with communities
• Change the emoticon
URLS (new for 5.5)
• Profile types and policies
(new for 5.5)
• Troubleshooting
• Start with clear logs & clear
<profile>/temp * wstemp
• Know where the logs are
• WAS, HTTP, Plugin, DB2,
Cognos, CCM, Docs etc.
• Start with Systemout and
work backwards
• Test against WAS (no
HTTP) if HTTP issues

24. Troubleshooting cont.
• Troubleshooting
• If clustered run only 1 node
up at a time
• Include all admins (LDAP,
DBAs, Network etc)
• Switch logs to English (if
not already)
• Remove proxies / firewalls
for a test (where possible)
• Install fiddler (Support will
ask for traces)

25. Thank you & Any Questions?
http://socialshazza.com
dilftechnical
@socialshazza
Hope to see you 15th / 16th September
http://www.iconuk.org
Registration, sponsorship & session
abstracts now open