The main challenges you'll have to face if you are looking forward to merging 2 service cloud orgs are both technical and business-oriented (which should have been scoped/refactored in a previous study):
TL;DR: There will be a need to review similarities and differences between everything used in their day-to-day business like SLA, support processes, case channels (email-to-case, web-to-case), knowledge articles, milestones, holidays, specific developments, governors limit (outbound emails per day), storage usage, legacy service console VS lightning service console, data migration matters, etc...
=> Merging two service cloud heterogeneous orgs implies to review everything that is used in each org, if they can be merged or kept, if they impact a functionnality or another one (service cloud cookbook might help you list all).
Sometimes, starting from a brand new org from scratch can be wiser than trying to put a a mammoth in a small swimming pool.
- Heterogeneous and similarities between support processes of the 2 orgs. In other words, you'll need to find out if 2 supports processes cover the same need and whether you need to merge them into one
- Milestone management and their associated actions/end dates. This impacts also the business hours and holidays you might have to merge
- Assignment rules, escalation rules, teams
- Web-to-case, email-to-case, auto-response rules
- Governors limits like for instance the number of outbound emails per day
- Data Migration and associated transformations if needed to fit the target org