Upgrading to Version 9

Our current BPM system is at 7.5, and we'd like to get rolling with version 9. I know -- or at least I think I know -- about three possible options:

upgrade our existing production system and processes to version 9 (of course, we'd have to upgrade to 7.6 first)
create a new v9 environment and use the side-by-side integration with the old environment so we can access our old processes from the new v9 portal
create a new and completely independant v9 environment which has no link to the old environment, and migrate our old processes (which would have to be at 7.6 before migrating) to the new environment.

Does anyone have experience with any of these options? Which do you think is best? Thanks.

Find more posts tagged with

BPM

Comments

Jerome_Pearce

2 is probably your only sane option.

The migration will migrate your existing processes (with some possible fixes reqiured), but none of the code will be migrated. If you want to change any of the code, you can only reasonably rewrite in version 9 - editing is just not an option IMO.

In effect, what you have is the ability to rewrite your processes bit by bit, rather than being forced to rewrite all in one go, but the fact is that it will all (all code at least) have to be rewritten. I'll apologise to any concerned party if they can refute that, as I have been berated by some for suggesting that this is the case.

Our experience is that it it an opportunity to redesign certain processes that have become overly complex over time. As we maintain processes up to 11 years old for some of our customers, that has been the case occasionally. Where the processes are not too complex and have not become difficult to maintain (as you can over 11 years), then migration is the better option.

For reference, overly complex in this context is over 10 integrated processes in a single solution with over 50 stages and over 10 forms in most processes.

Apperson_Rory

Thanks for your reply.

I should probably clarify that if I go with option 3, I don't plan on migrating the processes right away. We're fine keeping them in the 7.X environment for a while and slowly migrating, which I understand would involve some major code rewriting. As for option 2, we'd eventually have to migrate anyway because 7.X is only supported until 2012. So between option 2 and option 3, we're looking at a slow migration period involving some code overhaul, and given that, I'm just wondering if there are any obvious pitfalls I'm missing by considering option 3 (the independant environments with slow migration of old processes to the new environment).

Jerome_Pearce

Option 3 is the same as 2, but the users have to use two separate systems for their to do and watch lists is all. If they are OK with that, it may avoid a headache or two.

Carolyn Anderson

I am doing 3, and regretting it. If I did it again, I would do 2.

But I did manage to migrate my processes with a bit of tweaking (mostly on the sql-related parts and javascript).

I can't migrate my data over though, so my go-live has been delayed indefinitely till they fix the bug on the repository migrator that is messing with my data migration.

Which is why I would do 2 if I had the chance.

Apperson_Rory

Thanks Jerome and Carolyn. Jerome: what kind of headaches are you referring to with the side by side? That's the kind of information I'm curious to hear before making my decision. We are not in any rush to migrate (our users having to connect to two different systems is not an issue); basically, our migration schedule will most likely be driven by the end of support for version 7.X.

Brian Mellert

Interesting ... nobody for option 1 at all?

Actually, if we tried that approach, we'd be making a copy of the database onto a new database for fall-back options. Of course, even following #1 still has the "need to rewrite code" issues the others have. In theory it should get around the data migration issue though.

(This all pure conjecture on my part though. I'm not sure which approach we will take when we upgrade next year. Hearing so many issues even in 9.0.2 makes me nervous. Time will tell ...)

Carolyn Anderson

To upgrade, you need to create a clean v9 environment first and then deploy your projects to it, then migrate your data into a new v9 database, so no option 1 doesn't really happen. And I wouldn't advise anybody to install over the top of their existing environment without being 100% confident everything will work and all data will move across.

Jerome_Pearce

Roryap wrote:

Thanks Jerome and Carolyn. Jerome: what kind of headaches are you referring to with the side by side? That's the kind of information I'm curious to hear before making my decision. We are not in any rush to migrate (our users having to connect to two different systems is not an issue); basically, our migration schedule will most likely be driven by the end of support for version 7.X.

The only headaches are getting the side-by-side bit working. As all it does is manage alerts, making all alerts appear in one web site, and the v7 processes launch in the old web site, functionality should not be affected much.

I have seen a few issues discussed here and on our forums, but without knowing how many are trying it, it is hard to tell what the liklihood of isues is

Brian Mellert

Hmm, so its not even possible to upgrade in place ... well ... we could in prior versions, but this is a complete re-engineer. (I know we'd have to run the drop/create scripts for V9.) I didn't get the impression before that we had to move to a whole separate/new database instance, but my initial V9 environment was completely stand alone so we could see the basics.

From what I've heard about the migration tool, this will be painful ... though since it won't be until the next year, or at least the holidays, until we start looking at a V9 upgrade again, hopefully the migration bugs will be worked out before.

Carolyn Anderson

I got my 7.6 database and v9 database onthe same Sql instance, just separate databases. You need the metastorm engine/web install on a different server from where the 7.6 one was, at least until you're confident your testing has worked.

We have finally signed off for our go-live date today, so it can be done, depending on each company's prior use of the system I guess, though it has indeed been painful.