You’ve been told that you will need to go though Connections 6.0 to get to Connections PINK. We’ve been through the process already and can show you the best way to do it. From planning your data migration strategy, requirements and software upgrades, to time estimates and lessons learned and the all important documentation stage that everyone loves. Let us be the pain relief to your migrations headache (other antidotes are available).

1. Migrating to
Connections 6.0 –
Been there, done
that!
Sharon James
& Tim Clark

2. PLATINUM SPONSORS
GOLD SPONSORS
SILVER SPONSORS
BRONZE SPONSORS

3. Sharon James Tim Clark
• Senior Consultant
• Connections wizard
• IBM Champion
• Director of Services
• Domino Admin (ish)
• IBM Champion

4. What do you need to know?

5. What do you need to know?
• 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 PINK
components
– Test again
• Do not use all or nothing
– Can cause issues
– Difficult to debug
• Troubleshooting

6. What do you need to know?
• Your system must be at least V5 to go to 6
– If not you must migrate the DBs to V5 before you start
• 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 DBs 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

8. New Pink Features
• Orient Me
• Notification Center
• Additional features –
not magically installed
as part of the standard
6 install
• Linux Only
– RHEL 7 / Centos 7
– VM needs some power:
10GB Ram, 4 CPUs
• Runs on new Pink stack
of Docker, cfc,
mongoDB, redis etc

9. Last upgrade you will do this way ….

10. Get the right stuff
it’s not Rocket Science

11. Get the right stuff
• 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

12. Get the right stuff
• Check the system requirements
• Make a list (check it twice) ☺
• Get the correct versions
– WAS is mutli os, as are the fixes
(8.5.5.10/11)
– Connections– os versions
– TDI – os versions (7.1.1 fp6)
– DB2 – os versions (11.1)
– Other DBs – use supported versions – or
you may hit issues
Oracle (12.1.0.2), MSSQL (2016)
• Install a DB Client
• Install 64 bit (unless specified otherwise)
• 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
• PINK
– IC-OrientMe-6.0.0.x.zip – from
fixcentral
– Must set Linux as the OS or you can’t
find it

13. Get yourself a test system

14. Test System is a must
• ALWAYS test a migration – did we 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

15. Side by side Vs In-Place

16. NEVER do an in-place migration
• 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)
• 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

17. NEVER do an in-place migration
• 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)
• 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

18. Side by Side – best practise (sensible) way
• 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
• 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

19. Back it up

20. Back everything up
• Data bases
– ALL OF THEM!!
– Even if you are using the
Database transfer tool (DBT)
• 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
* We refer to this not restore the whole folder

21. Migration – use the K.I.S.S method

22. K.I.S.S – its not rocket science
• 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

23. Do not fall for ALL or Nothing
1. 5.X > 6
2. 6 + Pink
=

24. Never all or nothing
No quick wins, customer loses focus, many PMRS opened,
hard to resolve issues as multiple products with problems.
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.

25. Never all or nothing
Quick wins, customer has working system, easy to debug any
issues.
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
Total time 6 weeks

26. TEST, test and test again

27. TEST !!!!!
• Test a clean 6 system before
migrating data
• If in doubt test again before
installing / adding a new feature
• Migrate to 6 before adding PINK
features
• Get *REAL* users to pre and post
migration

28. What about this PINK stuff?

29. Pink is the new Blue / Green / Yellow
• Easy (ish) install on a newly
updated Centos 7 (or RHEL) box*
• Machine must have a resolvable
external DNS currently**
• For test/demo/small
environments a single VM will do
– Larger production environments
recommended 3 VMs***
• Disable machine firewall for
install
• Ensure you have installed zip
• Networking is configured correctly
• ***If installing on multiple VMS –
set NFS file sharing up
• This is the FOUNDATION for PINK
– As new features are rolled out they will
be deployed to this “OrientMe”
environment
* Take note of the system requirements (see the knowledge
center link on the next slide)
** work around for this here: http://bit.ly/PINK-DNS-FIX

30. Pink – install info
• Extract IC-OrientMe-6.0.0.0.zip
• Follow the instructions in
https://www.ibm.com/support/knowledgecenter/SSYGQH_6.0.0/a
dmin/install/c_install_orient_me_homepage.html
• Prepare the install files
• Run the installer script – downloads
and deploys Docker, CFC and other
associated software.
• DO NOT change the default CFC
password of admin/admin until
everything is configured
• Create the storage
• Configure Connections 6 TDI /
Profiles
• Install the Orient Me images
• Configure HTTP / Proxy
• Configure REDIS
• Run the people migrator for
homepage
• Fix for SSL
• Configure the notification center
• Test via
yourconnections.url/social

31. Note to
IBM ☺

32. And as if by magic … Connectios-Orientos-Pinkios

33. Post migration and troubleshooting

34. Troubleshooting PINK
• Check the datastores / pvs –
kubectl get pv,pvc
• Check the pods –
kubectl get pods
(use –o wide for more details)
• Check the services –
kubectl get svc

35. Troubleshooting PINK
• If you see issues with the pods
you can redeploy them
• Get the pod name from
running
kubectl get pods –o wide
• Simply delete it
i.e.
kubectl delete pods orient-
webclient-2180930634-2831s
• Pods recreate themselves
• If you need to delete all pods
• kubectl delete --all pods
• Pods terminate then recreate
• If in any doubt ask in the
Connections Skype chat – the
PINK devs are listening in

36. And you are done ☺

37. Remember this is the last upgrade you will do
this way ☺

38. Thank you / Questions
• Come and see us at our
booth
• You could win an
Amazon Echo Dot
• E - contact@bcc.biz
• W - www.bcchub.com
Tim
Sharon
http://socialshazza.com
dilftechnical
@socialshazza
http://blog.tc-soft.com
timsterc
@timsterc

39. PLATINUM SPONSORS
GOLD SPONSORS
SILVER SPONSORS
BRONZE SPONSORS