In 2012, we have seen an increased number of clients either migrating or evaluating a migration from Documentum to Alfresco. With significant changes in the last two years, we have decided to refresh our postings from 2010 as well as a client interview in 2011 where we presented detail on some of the justification to move from Documentum to Alfresco. This post will present some of the overall reasons why clients are considering moving from Documentum to Alfresco.
Traditional Disclaimer
This post is not written as a “Why everyone should migrate from Documentum to Alfresco”, but more of a description of why some clients are moving or considering the move. TSG was an active Documentum partner from 1996 through 2010, and is still very committed to the Documentum platform and our solutions running on both Documentum and Alfresco. As presented below, the decision on Documentum versus Alfresco is fairly complex and involves consideration of technical ramificaitons, development effort, software costs, maintenance costs, as well as relationship issues.
Vendor Relationship with Documentum – Engineering Culture to a Sales Culture
Many long-term Documentum clients are upset with their vendor relationship over the past 5+ years. We would summarize that the core of many of the relationship issues has to do with a shift from an Engineering culture to a Sales driven culture at Documentum. Some signs of movement to a Sales driven culture include:
- Aggressive software audit – We first started detailing clients’ issues with software audits back in 2005. Given the changes in pricing model over time, even clients that are vigilant in maintaining the correct licensing can fall-behind and can be subjected to a “gotcha” audit. The focus of the aggressive software audit seems to be more on sales for the quarter than a long-term relationship. Aggressive audits have left some clients looking for alternatives.
- Pricing Model – Somewhat tied to the software audit but the continued use of “named user” pricing can make it difficult to expand the use of Documentum to more users, as well as part-time internal or external users. The sometimes deliberate confusion of the different sales models can be confusing compared to simpler CPU based maintenance only pricing of Alfresco.
- Commitment to Research and Development – in the past few years, the delays in product releases, as well as the outsourcing of core product development, have left users frustrated with the lack of innovation/upgrade for the Documentum product components. Some products, like D2, have been viewed as a sales tool to give sales representatives more to sell to existing customers, rather than improving existing licensed products for clients.
- Consulting Division – Documentum aggressively has moved away from a pure-play software firm to one that looks to maximize revenue/sales from clients by offering consulting solutions, which can sometimes be a mandatory component of using tools like the SharePoint Development Framework. This puts Documentum in competition with their partners while reducing outside innovation and reducing customer choice for integration services.
Alfresco’s engineering focus is very similar to how Documentum was in the 1990’s. Some of our observations on how this impacts the relationship with customers include:
- Research and Development – At their core, Alfresco is an engineering company. Check out their management team to see their focus on CTO, Chief Product Officer, and Chief Architect as huge parts of their management team.
- CPU Pricing for maintenance only – Unlike a software purchase, there is only a commitment for paying maintenance with Alfresco and no software purchase. As John Newton likes to say, “We need to justify our cost to our clients every year”. The motivation of a “book it this quarter” sales push or software audit would destroy the long-term relationship.
- Innovation Partners – Alfresco has no capabilities for consulting and is solely focused on developing innovative partners that extend the platform, rather than competing for consulting sales with partners.
Why not SharePoint?
Two years ago, we struggled with where SharePoint would “fit” in regards to Documentum. One interesting post was about how either Alfresco or SharePoint could be viewed as a disruptor to Documentum.
At the time, we thought a significant reason why SharePoint and Alfresco were gaining ground on the ECM market and Documentum specifically given the push to Commodity Pricing component; the CPU pricing model of Alfresco for maintenance only, or that many organizations already own SharePoint.
Over the last two years, a number of factors has resulted our clients not considering SharePoint as an alternative. It is not so much that SharePoint couldn’t replace Documentum, but more a question of “should it”. Some of these reasons include:
- Collaboration versus Records/Document Management – The collaborative benefits and failure or success of SharePoint can make it difficult for many clients to be able to view it as a “system of record”.
- Reduced Capabilities – Experienced Documentum users just don’t find all the needed functions in SharePoint that are core to their Documentum systems. We have always struggled with SharePoint’s inability to store a PDF rendition, something that Alfresco and Documentum embrace, due to a focus on Microsoft formats. (Just keep it in Word).
- Non-Microsoft Momentum – Success of Open Source, as well as Apple and Google in the consumer market, make it harder and harder to justify a “Microsoft Shop” mentality. Clients like having the flexibility to choose non-Microsoft platforms and formats consistent with a “Bring Your Own Device” trend in consumer/enterprise computing. We see significant innovation in the open source Java world as opposed to the controlled Microsoft development environments.
Based on the points above, we really don’t see any momentum in clients moving from Documentum to SharePoint. This web series will focus on Documentum to Alfresco migration.
Upcoming Posts
Over the next few weeks, we will be posting additional comparisons between Documentum and Alfresco including:
- Solutions (Specific on Complaince Solution)
- Maturity of Platforms
- Cost Differences including (Buy or Subscribe)
- Controlled Documents
- Company Visions
- Alfresco as a front-end, Documentum for Archival
- SaaS and the Cloud
- User Interface Options
- Webtop Migration to Alfresco versus Upgrading to D7/D2/XCP
- Development Environment and Philosophy
- Migration Experience
- Workflow
- Support
Let us know your thoughts on perspective topics below.
Jorge Sapaj says
Hi,
As with all commercial software, pricing will always be expensive against an open source solution. However, I don’t see Alfresco on the same features nor performance levels that Documentum offers.
The maturity of Documentum platform is way ahead of Alfresco, and customers should first focus on what kind of system are they looking for. If scalabillity, integration facility, and general system functions are important they should choose Documentum. Certainly a license-only price evaluation is just a part of the story.
Are implementation services good enough? Normally Alfresco consulting shops are small business hunting small implementations, not best of breed Enterprise class companys. Also, Alfresco projects are usually seen as a application-specific focused solution than a Enterprise-wide unified ECM platform (same as Sharepoint). I have seen many failed Alfresco cases on Goverment institutions in my Country because consulting expertise is dramatically different on Alfresco and Document side.
Other items to consider is customer’s standards. I have seen on some customers that their IT standards dictate operating enviroments like Solaris, HP-UX and others that are not very Alfresco nor Microsoft-friendly, primary for performance or security concerns.
Finally, Does Alfresco provides the same level of functionallity? I mean, example: On Documentum you have a very good workflow engine OOTB. Do you have the same with a basic Alfresco install? Documentum Content Server works as an Application Server, which can contain business and object-level logic. Can you see Alfresco as an AppServer?. Documentum offers great solutions for engineering, compliance and life science, based on many years of consulting expertice. Does Alfresco has something like that?
TSG Dave says
Jorge,
In regards to your thoughts – some quick replies:
– Performance – we are going to address that in subsequent posts. We have found performance with Alfresco on par or above that offered by clients that have migrated. See our posthttps://www.tsgrp.com/2011/10/03/migrating-from-documentum-to-alfresco%e2%80%93-client-interview/ in regards to an interview. The client was suffering some stability issues so performance was hard to evaluate but on easily on par with Documentum.
– Maturity – Not sure I understand your point. Alfresco and Documentum are both “mature” – Alfresco has a better code base since it was all developed in Java from the beginning. When evaluating new offerings (ex: D2) we are not seeing all things Documentum as mature.
– Implementation Services – Most of the key Alfresco partners are ex-Documentum partners (like TSG, BlueFish, Zia and others). We all do big jobs. Would agree that not all partners are alike and can’t speak to Alfresco partners in your area.
– Standards – Alfresco is all Java – runs anywhere. We haven’t seen issues with our clients.
– In regards to functionality – look for subsequent posts here – we have had great success with Activiti (Alfresco BPM) that compares with BPM, not the Documentum Workflow tool.
Thanks for the reply – will try to address some of your concerns in the upcoming post. Overall message would be that, in regards to core functionality, we have seen Alfresco to be on par or above the offerings from Documentum.
Dave
Matt says
I wish you would add a section to this series called “Getting Started with Alfresco” This may be helpful for people that have administration, development and / or installation backgrounds with Documentum, but are unsure how to start in using Alfresco. Tips, websites and resources that you have used would help with adoption of this potentially viable option. Thanks for considering!
TSG Dave says
Matt,
Good point!!!! Will try to add to the web series as well as have something more comparitive on the website. Might be something like “Getting Started with Alfresco for Documentum users”
Dave
Paras says
That will be informative
Luis A. Sánchez says
Dave, thank you for posting and sharing your experience, it’s very valuable for us.
We’re an Alfresco Gold Certified Partner in Chile, and have a very good record implementing solutions based on the platform.
Jorge Sapaj is right in his point, many local companies are jeopardizing the brand, just because Alfresco is free to download and deploy. They do not get to the point that ECM is a discipline that brings value, context & compliance for the business.
Alfresco addresses those requirements quite well, but as Jorge has pointed out, some integrators lack the consulting expertise and technical mastering to deploy business critical solutions. They also lack the experience to design them with grow and sustainability in mind.
Regarding integration, business and object-level logic, they are also Alfresco strengths. For Alfresco, everything is a node, and node wraps metadata, as content, as business objects, associations and states, to mention a few.
Last but not least, Solaris, HP-UX, AIX, Windows, Linux, they’re just OS. Alfresco runs where Java does. Alfresco can run inside WebSphere, WebLogic, JBoss, Tomcat, Glassfish, and could use Oracle, DB2, SQL Server as back end databases. I think platform support is one of their bests.
Please keep posting about the matter, regards.
Luis
ukdavo (@ukdavo) says
Some of Jorge’s ramblings are painful to read…
I’ve worked with Documentum since 2000. Documentum _does_ have great product breadth. I agree that the core repository is robust. WDK – again proven technology albeit very long in the tooth. D2, err no not proven. And they’ve gone backwards on key integrations like MS Office, Outlook & SharePoint. The out of the box workflow is pretty crap really – no one uses it today. BPM makes it usable and really should be included out of the box, not an added extra. Process Builder is a useful tool & I’m looking forward to seeing it merged with Forms Builder & Composer..
..however Composer (and DAB before it) can be hit-or-miss. Its normally OK but when things go wrong its a world of pain (e.g. mixing Composer project versions). I actually prefer the Alfresco approach where you define the object model in XML because there’s no black magic involved. Alfresco need to do something about hot deploy of customisations though. Having to restart the container to deploy AMPs sucks. How about using OSGI?
Re stability I’ve logged so many DCTM product bugs that I can’t really say that its any better than Alfresco in this regards. All software has bugs. For example, DCTM still has the weird and wonderful limitation in that lifecycle promotions can’t be wrapped in a transaction. And a personal irritation of mine is that checkout via CMIS checks out the entire version tree (I mean, really..). What matters is how the vendors deals with faults. Both companies seem pretty good in this respect. I’ve been able to speak to engineers in both organisations.
In terms of performance, Alfresco beats the cr*p out of DCTM – especially if WDK is being used. Documentum does not have a reputation for being fast. I mean really – give yourself a shake man..
Scaling large ECM systems is not straightforward. I’ve seen botched high availability DCTM systems – not really a surprise because the documentation _still_ doesn’t correctly describe adding a 2nd content server. The one thing that I’ll say about DCTM is that the repository _is_ proven at handling huge numbers of objects. Alfresco is also very scalable but I’d like to see Alfresco make more of of an attempt to prove their technology in this regard.
That turned into a bit of a rant. Sorry about that :-]
Jorge Sapaj says
@ukdavo: I had been working with Documentum for 12 years and disagree about going backwards with key integrations. Currently, D2 has excellent integrations with Office and Adobe, for example, D2 provides a function to compare documents and versions of the same document. There is a DCO (Documentum client for outlook) product and a MyDocumentum for Sharepoint product.
You are right about mixing Composer versions is difficult but. Why this should be a case? You should always use the same Composer version than the Content Server. And it’s very easy to migrate Composer projects to newer versions. The issue here is more about developers discipline and DEV enviroment standarization than a product issue. Once you learn to correctly use Composer it turns into a great tool.
I share with you the LifeCycle issue with transactions. it generates some degree of concern because you have to be clear of what happens on the Content Server doesn’t get auto-reflected on the client side so you must program with this concurrency limitation. The technical explanation for the LifeCycle issue is that Lifecycles perform their validations and actions in a transaction as a whole. So there is no need for you to work with transactions inside Lifecycle custom code.
Regarding bugs an stability, you are missing something important. Never use a product on a “.0” release (I mean, without service packs). Also, you should always get to know the version you are working with before taking into a serious PRD project. I mean you should always invest some time on R&D.
About scalability and adding a second Content Server. I must say that this topics a very well covered on Documentum System Administration courses. I have personally used that feature for some customers and works very well. Consider that you don’t need a cluster to get HA or load balancing with Documentum. it’s actually one of my favorite Documentum features. Remember always setup a test environment to get familiar with the product and spend some time on classes and R&D.
ukdavo (@ukdavo) says
@jorge – I’ve not attended the sysadmin course but I’d be interested in whether the advice is diifferent to the documentation.
In my experience, the undocumented traditional method is to manually create a 2nd content server without using the CFS script (which is more for distributed setup than HA – check the proximity values if you don’t believe me), manually copying over AEK key & config files, creating private docbrokers for the method servers and pointing other clients at public docbrokers, etc. I realise that Trusted Servers in 6.7 helps with HA setup.
I appreciate your response to my post even if I may not agree with everything you say. At least it comes from a position of experience and knowledge, unlike your ridiculous assumptions about Alfresco.
Jorge Sapaj says
@ukdavo – So you treat me like “ridiculous” but you just made the same on your first post for not being correctly prepared to work with Documentum? I expressed concerns and asked questions. I don’t have any experience with Alfresco but I am very interested in getting to know the product as a valid alternative for Documentum specially for small implementations.
ukdavo (@ukdavo) says
Not correctly prepared to work with Documentum? You’ve made some baseless assumptions about Alfresco. Please don’t make equally absurd assumptions about my background.
Jorge Sapaj says
Baseless?: From your post: “I’ve not attended the sysadmin course”… you said it not me…
ukdavo (@ukdavo) says
@Jorge So I’ve not done the sysadmin course. Whoop de doo. Too busy working mate..