Upgrade or Convert RoboHelp 10 to RoboHelp 2017

[ohiouniv3]

Has anyone upgraded from RoboHelp 10 to RoboHelp 2017?  What was your experience pros/cons?  Did you run into problems? What kind?  I know I asked a lot of questions, basically I would like a summary of your experience in upgrading and converting projects from 10 to 17. 

[Peter Grainge]

A fair few thousand I would guess.

There shouldn't be any issues but there can always be a project that has something unique. Backup first.

---

See www.grainge.org for free RoboHelp and Authoring information.

@petergrainge

[Amebr]

I haven't got any experience upgrading from RH10 to RH2017, however, I try to do the following before I upgrade.

1. Delete the cpd, open the project and check that links are fine, topics and images are all displaying as expected, and do a fresh compile (no need to publish).

This is just to check there isn't anything funky cached, and you have up to date RH administrative files. Sometimes I've found that topics that seem to be fine mysteriously vanish after deleting the CPD and this gives me the chance to fix up anything strange.

2. If possible, make sure the project is on the C drive, but not in your user directory (Documents folder, Desktop folder, etc) as this is sometimes actually on a network because of corporate policies. The network could experience slowness or some sort of glitch preventing some files being updated. (I try to always work somewhere like C:\Projects\, but I know this isn't always possible depending on the company.)

3. If source control is used, manually check out the entire project, to ensure all files are writable. Sometimes I find RH won't check out some files it needs to update, and then something falls over.

[pault4511844]

Coincidentally, I've just completed a migration from RoboHelp 10 (10.0.0.287) to the RoboHelp 2017 Release 1.

We subsequently upgraded to RoboHelp 2017 Release 2 (13.0.2.334) following our migration.

This was successful in the end with no major problems encountered.

I can share the things I considered & the risk mitigation approach taken to ensure our production project was exposed to minimal risk.

We have a relatively simple structure for WebHelp. We have around 4,000 topics (html files) within our project. We don't use any map files for context sensitive help(CSH), preferring absolute paths within our software application. we don't use project merging, we dont' use the version control features & we are not users of the RoboHelp Server.

Risk Considerations:

When considering the upgrade I had risk associated concerns around the following:

- compatibility of our 2010 project within RoboHelp 2017

- compatibility of our 2010 project with the HTML5 Output Generation

- Potential issues around use of GITBASH with the newly converted 2017 project (we use gitbash to to 'pull' & 'push our entire webhelp 'from' & 'to' our trunk software since we use context sensitive help within our application which allows our software users to hit F1 on any screen to access the relevant webhelp Help page.

Upon purchasing several licences directly from Adobe for 2017 (note a brand new licence is required for this, whereas if upgrading from 2015, a lower cost 'upgrade' licence can be purchased), I had a call with the tech comm team & they were upfront on the fact that they had not had any experience with any customers upgrading from such a low base but advised it would probably be fine.

We tested the entire upgrade using a 'copy' of our entire project in a test environment with each 'risk consideration' in mind. We were able to open the 2010 project successfully within 2017 and encountered no upgrade related issues during this testing.

2 minor challenges we did meet which were overcome:

- keep your project directory short,

e.g. C:\webhelp\ reason being is that there is a 256 character cap. we had several project files which breached this limit so encountered error's for each case open opening in 2017. bringing our entire webhelp directory up several directories within the drive resolved this.

- Production of Responsive HTML5 Output withing 'Output(SSL)

When we first opened our 2010 project within 2017 & viewed the 'output(SSL)' Pod from the menu bar, the output Type 'Responsive HTML5' did not appear by default within our list within the pod on the left side of the screen.

It turned out that all we needed to do was to click on the 'Create Output' menu item within the Outputs(SSL) pod & selecte 'Responsive HTML5' as the output type & work from there.