Migration Flare -> Flare

[simona]

Hiya everyone!

Calling the awesome Flare hive-mind for help - if you have migrated legacy documents from Flare to Flare or initiated global project linking (GPL) I'd love to hear from you!

Here is my attempt to summarize the project situation as concisely as possible:

- >50 products (SW and HW, all RUO classification)
- >5 document types (e.g. User Manuals, How To Tutorials, various validation documents)
- primary target = PDF, secondary target = HTML5, primary language EN-us
- some translations (handled externally) to some European languages as required by product management
- >100 still valid legacy documents already in Flare (the rest is word docs)
- 1.5 technical writers with MadCap Flare experience on the team
- all 100+ Flare projects are product-specific and in SVN, they get updated between 1 and 4 times each year because products follow different (inconsistent) release schedules
- all documents are between 20 and 200 pages (PDF), some projects >500 pages, some have 200+ images in them

Currently, most of these Flare projects are not really suitable for single-sourcing and the ease of maintenance is poor because they have been edited by various tech writers based on various style guides over the last 15 or so years. When we edit a project, it always prompts a lot of manual tasks, copy & paste from word drafts, finding workarounds for small CSS things. There are a lot of inline styles, the project structure and TOC is different for each project and images are a lot of manual effort.

So everyone knows that something should happen but we have no resources or stakeholder buy-in to drive the needed change ourselves. We - as in the Technical Writing team - have tried for 2+ years and want to work better, but it is difficult when daily tasks leave such little room for project work and process improvements. We are in the process of setting up a new global project prototype and would like to migrate all legacy content to the new Flare project structure (based on global project linking), but IT support internally is rather slow to come by and we have little knowledge about version control systems within the core team. We are wondering if Central might be an option... we just want to increase ease of maintenance!

Well, surely we are not the only tech writing team with such a challenge? Surely there is something we can do? I have worked with Flare for over 10 years and know it is capable of much more if set up properly!

What would you do if this was your project?

PS: I've searched for similar threads on Flare migration but couldn't find any, please point me in the right direction if there are any I may have overlooked - tia!

[IFU]

Hi Simona
Sorry - no words of wisdom to offer but I share your pain. We are in a very similar situation (lots of products, multiple product versions, many deliverable types, PDF and HTML outputs, translation, SVN for source control, regulated industry, etc.). We have not set up global projects yet because it is too daunting - no time to research and we can't afford to make mistakes.
Isabelle

[scap]

So everyone knows that something should happen but we have no resources or stakeholder buy-in to drive the needed change ourselves. We - as in the Technical Writing team - have tried for 2+ years and want to work better, but it is difficult when daily tasks leave such little room for project work and process improvements.

This is the crux. You need to get support from above and a semblance of buy-in across the business else this mammoth task cannot be done.

Find allies and build a business case.

[ChoccieMuffin]

When you DO get buy-in and permission, there are a couple of things that might help reduce a tiny bit of the inevitable pain.

1. Make sure your writers all have the same file/folder structure on their machines. So, for example, if you have your global project in D:\Flare\Global and your child projects in D:\Flare\Child1, D:\Flare\Child2 etc, then make sure all your writers have the same structure and same letter for their drive. (This is to allow you all to use the same import files in your child projects when importing from your global project.)

2. Define the styles you want to end up using for all your docs, in your global project. If for example your projects have a range of different stylenames and stylings for your regular body initially you'll be able to do something like, this, where what you want to end up using for all your projects is "p.body" but some other projects call it p.BodyText or p.Normal:
p.body,
p.BodyText,
p.Normal
{
(((settings)))
}
Then once you've imported your global project you can do some search and replace actions in your tidied projects to change "class="BodyText"" to "class="body"", and the same for other styles.

3. Do AS MUCH TIDYING AS POSSIBLE in your child projects. Yes, I know this is difficult, but try to remove inline styling as much as you can in your child projects, and if necessary add styles to your global stylesheet. (For example, you might have just applied BOLD to any software terms, so in your global stylesheet define a span class, e.g. "UI". When you work through your child projects you can look for instances of bold and apply span.UI instead.

4. Do one project at a time. It's not a race. They're all inconsistent at the moment, so you won't be making things worse.

5. As you work on each project, set your targets to use the stylesheet you import from your global project rather than the stylesheet that's currently in there.

6. Include other bits and pieces in your global project that you want to be consistent across all your projects, such as page layouts, template pages (used to be called Master pages), condition sets, variable sets, skins, fonts, corporate images, table styles, and bits of content like copyright text that is used in all, or most, of your projects.

There are lots of other things I could throw at you, but work calls. Good luck - it's not a small project you're thinking of, but if you can define your global project first, then tackle the child projects one at a time, you'll get there.