Data migrations are my bread and butter and data cleansing is indeed a hugely important matter. One strategy we use do migrate 100% of our customer's data is asymptotic data cleansing pre-migration tools.
This means developing tens of data-sanity checks (mostly sql queries).
Exchanging cleansing tools with the customer (since that's his data, we design the patching utilities, he validates them and executes them).
Refining the tool over iterations and reaching KPI-backed measurable quality asap.
Checking data consistency after the migration has happenned. This helps to make GO/NOGO decision on D-Day.
In the end a data migration is an immensely beneficial exercise that has to happen after 3 to 5 years.
It allows to boost the platform's ability to support business.
It allows to streamline the database.
It prepares the IT platform for next generation business tools (ESB/EAI, Portals, Self-Care platforms, reporting and data mining, you name it).
It reorganises DIY data flows between platforms that have accumulated over the years in a quick and dirty "temporary" way to fulfil "urgent requirements".
Above all it empowers the IT production team who come to know their platform better and foster 'can-do' attitudes. These kinds of benefits are difficult to measure but when you come to know many clients, this consideration becomes obvious. Companies shying away from migrations remain in the following tier, bold ones lead the pack.
It's a little bit like when the basement of your house becomes cluttered with lumber. One morning, you have to take everything out and put back only the things you need and throw the rest away. After that, you can use your basement again ;-)
Another fundamental consideration is that nowadays, customer expectations are always on the move, as in "customers are always more demanding". So that there will always be a significant proportion of a given company's competitors on the lookout for these new trends with the obvious intent to increase their market share. The way they will do so is by adapting their offering to stick to the trend or even drive the trends, and that entails constant business re-engineering. If your IT platform is too rigid, it will be a drag on your own aptitude to spouse or precede the market trends on your own side and, ultimately to maintain your own market share. In other words, in a moving market inertia is a recipe for irrelevance.
In contrast, a data migration to a newer system will roll out a more modern and more versatile productivity tool, making the best of newer technologies, more attractive to employees and this in turn, will contribute to support or even lead the company's internal innovation process, thereby securing or increasing its relative market share.
The considerations above actually answer only half of the question asked in the title "Data Migration - dangerous or essential". Yes Data Migrations are essential, but are they also dangerous ? On this account, many things in IT are dangerous then. By definition, anything where the stakes are high is dangerous; especially if you do not take the matter seriously. But this is actually the most common pattern in IT. Not taking data-centres or high availability or disaster tolerance seriously is dangerous.
Does that mean that today's companies should opt out of these pillars of today's Information Technology landscape ? Surely not !
To make your point jokingly, you could argue that "Flying is dangerous if you don't use a plane made by professionals". It's the same for Data Migrations. When executed and conducted by professionals, it is no more dangerous than flying in a well designed and well operated plane. And ROI is in the same proportion compared to terrestrial means of transport.
When entrusted to professionals, most migrations are well controlled successes and the failure+abandon rate is extremely low.
Your managers should be led to ask themselves "Whilst most companies go through Data Migration projects successfully what would make our company so different that it would instead experience a failure ? and can it fare well without one ?"
Short answer
You should consider that it's a very risky and costly idea that may not give you as many benefits as you think it might.
Long answer
You should consider the following:
C++ is a language that can be used at a very high level, that is cross platform (though that depends on how much you used the VC proprietary extensions) and for which many very mature tools exist. C++11 will add even more juicy bit to handle annoying use cases.
If you're thinking about a full rewrite, don't forget that rewriting fully debugged code is time you won't be implementing any new features. If you don't have a clear benefit for using C#, this is throwing money and time through the window.
If the team knows C++, then for a long time writing code in C# will be slower despite any advantage that C# brings.
You have two option for migrating your apps : restart from scratch (and see http://joelonsoftware.com/articles/fog0000000069.html , already posted), or add new features by maintaining a mapping layer between the C++ and C# code. While C# is quite good as far as calling native code go, it's still some pretty complex code to write. If you either use P/Invoke or C++/CLI, both will force you to know much deeper detail about the platform than would be required for a pure C# solution. Also, you'll spend an awful lot of time marshalling data between managed and native code. A better option may be COM, though I hope you like ATL programming.
The biggest benefits of C# are its simplicity and garbage collector that free you from thinking about a lot of corner cases. That mean it can be developed by developers that are less hardcore than what you need for C++. In your case, your team already know C++ so those benefit are much less present. If you use unique_ptr, shared_ptr, RAII and such, much of the dangerous part of C++ can be managed. Yes, you have more options to shoot yourself in the foot, but you avoid the dangerous parts.
But still...
If you're not talking about a full rewrite, yes, it could be possible to develop some part of the application in C#. But always keep it mind the cost of the mapping layer between C++ and C#. I would recommend exporting your C# parts as COM modules and calling that from C++. Be sure it bring a real advantage. If you must constantly convert vector<> to IList<> and must constantly convert your C++ type to C# one, any speed advantage of C# will be lost. You gain most of converting to C# and .NET when everything can stay inside the CLR. Getting everything inside the CLR mean a complete rewrite of a complex application and that is dangerous proposition.
All in all, I wouldn't recommend it.
Best Answer
Java 6 has reached EOL in February this year and will no longer receive public updates (including security) unless you buy very expensive enterprise support.
That should be all the reason needed.
Besides, overwhelming evidence suggests that backwards compatibility for Java runtimes is excellent. Chances are that you just have to replace the Java 6 installations with Java 7 and all applications will just continue to work without any problems. Of course this is not guaranteed and extensive tests are recommended to confirm that there will indeed be no problems.