I believe AxoSoft needs an OnTime to OnTime migration tool.

I am on OnTime 2006 and want to move to 2008.  This new version not only has a load of new features that I want to use but these features need configuring.  I also want to take the opportunity to revise sdome our existing OnTime config.

What I'd like to be able to do is install the new release, setup and configure and test everything and then when I'm ready to go-live MOVE the items from 2006 to 2008.

The problem with the current method is that I have to keep OnTime shutdown while I do the upgrade, setup all the new features, reconfigure the existing workflow, filters, Views, security etc.  This could take days!

Graham

 

Graham, our recommendations for upgrades to have a separate backup of your production database, then do the upgrade on that database while you run new and old versions side-by-side. You do all your testing, configuration, etc. on the new database and when you have everything setup exactly the way you want it, you write down all your changes and configuration of new features, then upgrade the production database and apply the changes. Although it could take days for you to figure out exactly how you want things configured, re-applying those changes to the production database should only take minutes.

Hope that helps. 

---

Hamid Shojaee
Read the Ship Software OnTime Blog
Axosoft, LLC

This is exactly what i'm in the process of doing, but we're going from OnTime 2005 to OnTime 2008 and with the massive changes needed the total migration time looks like weeks rather then days. The weeks worth of work is just on my end it won't effect the OnTime users. The re-applying of changes i'm hoping to take one day, but i'm certainly not expecting it to take minutes. We might be making a lot more changes then normal, but it seems like there is a lot of tweaking unless you're going with a setup close to the default. I am very excited about the OnTime improvements and new features, and I was the one to push for the upgrade. I wish there was an easier way to migrate then setting up a test system, documenting all the changes then re-apply everything though. Admittedly I don't see a solution, but I hate having to repeat all the manual labor, which I don't enjoy. It's also hard to keep track of everything I change as I need to make test changes and roll some changes back, or I don't want to enter all 100 new pick list items as i'll just have to enter them again. There are a lot of things to keep track.

 Oh, and 8.1 looks great, of course I just got done installing 8.0 as my test system.

-Adam

Adam, of course, the amount of work for an upgrade increases with each major release that is being skipped. In your case, you're skipping 3 major releases ahead (from V5.x to V8.x), so I can understand that the changes can be substantial.

However, one way to break things up is like this: There are 2 groups of changes:

1) Must-have Configuration Changes - These are changes that you need to make to V8 to allow your team to function similarly to how they function with existing version.

2) Nice-to-have Configuration Changes - These are configuration of NEW features that you want to take advantage of.

The amount of configuration changes in group 1 is relatively small and should only take a small amount of time to complete. Group 2 configuration changes can be applied over time rather than all-at-once. I can see the appeal of doing it all-at-once too, don't get me wrong, but you could introduce the group 2 configuration changes over time after you go live.

Just some things to keep in mind :-) 

---

Hamid Shojaee
Read the Ship Software OnTime Blog
Axosoft, LLC

Can I assume the recommendations apply to the version 8.0 to version 8.1 upgrade as well?

It would be good to have a list of what might need to be reconfigured after the install.

Thank you!