Cognos Analytics primarily runs now on java (DQM) - this means we are using Java for the query engine (the heart of Cognos). All the new features of Cognos depend on being able to use either the compute engine (Spark/Flint) or java (JDBC and Java). Because IBM is committed to supporting all the older content we have, the CQM engine is still available and in play today.
My co-worker Ryan has written a really great article that details the three options and how and when (or if) you should choose to use each. It's a must-read to really understand what is going on with these engines.
Making that decision to upgrade old content (built using CQM) to DQM has been the main conversation I've had with customers since 2012. While switching from CQM to DQM in FM models is essentially just flicking a switch, we are talking about changing the engine that generates your SQL statements so this goes from simple to complex pretty quickly.
Ryan mentions that he's quoted these upgrade projects from 8-32 weeks and he isn't wrong. This switching of FM models could be seamless or a disaster. Yay! No stress there!
The reason this is so complex is that CQM was pretty forgiving of bad modeling. We paid for that in lots of ways but essentially, it would let us just do whatever we wanted with modeling and it would helpfully fix things so we would still get the right answer (most of the time). That forgiving nature lets us build bad models and then let us fix things in reports in sometimes crazy ways. CQM is the helicopter parent who fixes our problems so we don't have to worry about too much.
DQM is much less forgiving. It forces you to be "right" when you model and it doesn't fix your mistakes. Tough-love parenting - forcing us to be better modelers.
When it comes time to decide if we should upgrade from CQM to DQM, the modeling design needs to be considered. How well was the model modeled? Sometimes what we recommend, if we think the model is mostly modeled "correctly", is that you take a copy of the model, convert it (flick that switch), and then take a copy of a lot of reports and point to that model and see what happens. Do you get the same results in the reports? Are there a lot of errors? Then you can make a better decision about whether to upgrade the model officially.
So if it's likely to be complex, and you are planning on remaining on-premise (not cloud) Cognos, our recommendation is likely going to be to stay on CQM for that model and any new models should be developed in DQM (the default).
The issue comes if you want to move to Cognos on the cloud (IBM SaaS). That's when we are forced to upgrade our old Cognos models to DQM. This is where the real decision comes in: Do we spend time on the upgrade or do we start fresh and re-create this model? Do we do that in FM or in Data Modules? Like lots of things, there isn't one answer to this problem. It's 60% science and 40% magic. (Just kidding - I wish there really was Cognos magic! I always wanted to be a wizard. New business cards title: Cognos Wizard! Anyway, where was I? Oh yeah, DQM and CQM and data modules....).
For a long time, I would have come down on the side of rebuilding in FM in DQM but every new release pushes me more towards data modules. As an old-timey Cognos person, this hurts me to say it but it's time to say 'goodbye, old friend' to Framework Manager and to say hello to data modules. I'm not sure I would spend much time rebuilding in FM unless I had to for the few things data modules don't address (see Ryan's article comparing the two: http://ibmblueview.com/framework-manager-vs-data-modules/ ).