Disadvantages of Vantive

I would like to find out any daily operational constrains and issues on Vantive. Basically, all the disadvantages of Vantive.

The situation is like this.

We currently use Vantive to handle the Customer Management/Order Capture and Order Management.

Thus it would be really helpful if you could share some thoughts on the (Question 1)disadvantages of Vantive to aid in substantiating the argument of why we would suggest replacing their current Vantive system with something else, say Siebel.

It would also be great if you knew of anyone who have successfully migrated from Vantive over to Peoplesoft. (Questions 2)Some information on the effort required would certainly help us on this case.

(Question 3) How difficult is it to integrate Vantive with Chordiant and KXEN for analytics.

Popular White Paper On This Topic

The biggest disadvantage to Vantive, in my view, is that it's no longer supported. You're also missing out on the benefits of Internet Architecture and SOA.

There are scripts available from Oracle that will move your data from a Vantive database to a PeopleSoft CRM database. However, your customizations are another issue. Since there is no way to easily convert VBA and Stored Procedures into PeopleCode and COBOL you will basically have to rewrite your customizations in PeopleSoft. That could be quite an undertaking depending on the degree of modification you've done to your Vantive product. Having said that, it would probably take less time and money to convert to PeopleSoft CRM than to implement a new product from scratch.

Vantive is an outdated application, with no real web interface,
based on old technology, which is no longer supported. It has
lots of annoying features like locator screens. It is not
compatible with latest versions of OS, DB and is hard to
intergrate with other applications.

However there are many features that are in Vantive's favor.
Vantive is an intuitive, easy-to-use application. Your company
has invested a lot of time and effort into buying, implementing
and customizing Vantive, as well as training your users.

So what are the alternatives?

There is not much of a migration path to PeopleSoft. Basically
any products from Oracle (PeopleSoft, Siebel etc.) would be
equal to buying a 3rd party application.

All your customizations would be lost. Your Data migration would
be a painful process. Someone on this board mentioned doing an
implementation from scratch. Well in this case your historical
data would be lost, your unique business rules would have to be
reengineered and your users would have to be retrained.

There is a middle ground however. There are companies on the
market that help companies save legacy applications like
Vantive. One of such companies you can check out is called
Queplix. There might be others - I am not sure.

From what I know - Queplix can upgrade Vantive to J2EE platform,
while keeping the existing datamodel, all customizations, as
well as Vantive business rules, workflows and GUI look and feel.
Another words they can help save investment your company made
into Vantive.

Just wanted to add to the previous post, that Queplix converted a
lot of Vantive customers as I know, mostly in the Enterprise
world. My vantive to queplix project was for global conversion
of around 30 contact centers running Vantive. The whole thing
was done in 8 weeks(!), including database conversion to sql
server 2005 and optimization of performance! Let me know, I
would be happy to share my experience with queplix conversion.
Overall, we did not beleive that it was possible to do in few
weeks, but it was done. As much as our users loved Vantive, it
had to go since we could not run it on the old hardware anymore
and we had a long list of things we needed to implement. Queplix
guys were on site and first converted the Vantive as is, and
then offered lots of enhancements. We were considering going to
peoplesoft or siebel, but with Oracle's shopping spree our
management thought it would soon be the same situation as we
have with Vantive now. So queplix was a natural solution for us,
and we own the code now in case anything happens down the road
(like Oracle buying out these queplix guys) :)

Jeremy, I would be very interested in following up with you. I
would like to ask you if any decision has been made, or you are
still in the process of making a business case for Vantive
replacement? My company has done many Vantive conversions to
date and we can help you put together a business case and let
you make your own decision. Let me know.
thanks,
Steve

Where do I start :)
Let's just start by saying that any legacy migration to another product,
no matter what the legacy is and what the other product is, using
traditional methods is a lengthy, costly and painful process. Just ask
an army of data consultants who make their living in this field. To add
to the technical difficulties, Vantive did not enforce relational
integrity in their database, used proprietary formats to store data
(like attachments, etc.), data schema designers had no idea what data
normalization is, etc etc. The product was discontinued and end-of-lifed
many years ago. So why do some companies still using Vantive?
Based on our experience, here are the top reasons why companies keep
Vantive around:
1. Vantive has been customized to a degree where it fits the business
model to about 80%, which is by far than any other off the shelve
product can achieve, without going into years of customizations again.
2. Vantive is relatively stable, even though it is dragging entire
infrastructure down, by not allowing upgrading database, hardware or OS.
3. Users have been trained
4. Company's management does not want to repeat the same mistake and
burn millions on the new system, just to find themselves in the same
situation again few years down the road. After all, this is what
happened with Quintus, Scopus, Vantive, Clarify, Remedy, Siebel,
Peoplesoft, JD Edwards... the legacy CRM list is huge.

I believe an open source product in combination with legacy conversion
is the viable alternative to replacing vantives. It solves both
problems: allowing you to keep investment into legacy, while eliminating
the problem with vendor lock-in. Also bringing the latest features (i.e.
AJAX GUI, thin client, Google Search, gadgets, etc.) on top of the
legacy conversion.

One major difference: Sugar is SFA, while Queplix is Customer Care.
Also, Sugar is php-based, while Queplix is J2EE with Google's GWT, made
for larger enterprise (check out both companies' list of customers).

Sugar is disributed under SPL, which is not open source, however they
recently switched to OSI approved license. Queplix was always
distributed under Mozilla license through Google:
http://code.google.com/p/queplix so there is no attribution clause.
Queplix has OSS version and Enterprise version, both running on the same
core, but enterprise having additional enterprise modules.

Back to the original question - working for a company that offers free data migration as part of some of our deals, and also as the one performing the migration some of the time, data migration issues always have to do with the quality of the data after exporting from the existing system as most current systems have an importing wizard to help with the importing process and field mapping.

The area that may cause you trouble is exporting from Vantive, both with the quality of your data (duplicates, spaces in places there shouldn't be spaces, etc.) and how much control you have over the export with Vantive (selecting which fields you want exported, ability to rename those fields before exporting, etc). With no experience in migration from Vantive this pretty much concludes my advice, but after migrating data from Goldmine, Salesforce, ACT!, Outlook, and others, I wanted to fill you in on the major issue I have encountered.

If you have control over which fields are exported from Vantive you may want to get an idea of the fields required for the import into your new system before exporting from Vantive to ensure the smoothest import.

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.