Major new app version - new Product in LimeLM or not?

I plan to roll out a major new update for my application at the end of this year, which will be a paid for upgrade by users. I have had a v1 version of my app out for about 4 years now, during which time all upgrades were free, and the existing installation was upgraded. This time, the new version will install alongside the old, so that users can run either.What is the best way to approach this as far as LimeLM product/product versions is concerned? In testing, I have created a new "version" within LimeLM which creates a new .dat file and generates keys that are entirely independent from the old ones (i.e. it behaves as an entirely separate product). I'm now wondering if I wouldn't be better off just using a new "feature" on the old keys. Can I then have two separate applications that use the same LimeLM product? (it wouldn't be possible to run both at the same time). Part of my reasoning here is that users could offload their old product keys (for the old version) if they are given a new one - maybe I'm over thinking that bit. Also of course, assuming I get a decent upgrade %, I would end up with far more active keys within LimeLM.

What is the best practice here?

>> "This time, the new version will install alongside the old, so that users can run either."

If you're new version will run alongside the old version, and you'll be using different versions of TurboActivate (for example 3.x with the old version, and TA 4.x with the new version), then you should use different products or different versions in LimeLM.

>> "Part of my reasoning here is that users could offload their old product keys (for the old version) if they are given a new one - maybe I'm over thinking that bit."

If you're worried about that you could always set the number of allowed deactivations for the old version's product key to 0. That way they'll be able to deactivate their new key, but their old key is "stuck" to whatever computer it's currently on.

>> "What is the best practice here?"

Well, the most typical use-case for free upgrades is to completely remove the old version and install the new version. This way there is less confusion for the end-user.

But it really is up to you.

> If you're new version will run alongside the old version, and you'll be using> different versions of TurboActivate (for example 3.x with the old version, and TA 4.x> with the new version), then you should use different products or different versions> in LimeLM.

So would this actually cause an issue if I tried it with the same LimeLM product? Say last of the v3 on the old version, and v4 on the new? But it shouldn't cause any issue at all with different LimeLM product ids, right?

> Well, the most typical use-case for free upgrades is to completely remove the old> version and install the new version. This way there is less confusion for the> end-user.> > But it really is up to you.

True - and all of our upgrades so far have done this. This upgrade is a little different, in that is is 1. a paid for upgrade (our first) and 2. there are a lot of changes, including minimum system requirements. Not everyone will want to upgrade, I guess, and some that do may want to keep the old version as well (they will certainly want to keep the old version whilst trialling the new one). My hope, of course, is that they willingly uninstall the old one and go with the new one.

>> "So would this actually cause an issue if I tried it with the same LimeLM product? Say last of the v3 on the old version, and v4 on the new? "

Yes; only if the customer will be running both versions of your app simultaneously. If they're just updating to the new version of your app, then no problem will happen. TurboActivate 4.0 will just upgrade the license to the new format and everything will work better than before.

>> "But it shouldn't cause any issue at all with different LimeLM product ids, right?"

Nope, none at all.

Reply
Discard post