I'm a practitioner that initially reserved a high-degree of skepticism on the HANA promise. That is, until I had the chance to put HANA to the test. My findings? There's a lot of conjecture floating around about HANA. It's new so there's not a lot of 1st hand experience being shared.
HANA is the real deal and that's based on 1st hand experience.
I invested in and led a development team that took an Oracle DW, pointed the DDL at HANA, ran the existing ETL and loaded the new HANA tables all in just a couple days. The ETL jobs and the existing report queries showed immediate performance improvement with very little development effort.
Then we got after building an application that included mapping and loading of additional source data to the integrated data schema on HANA, triggering event-based invocations of statistical scoring models (R), generating dynamic messages & alerts to mobile devices, capturing and committing write-backs from the mobile devices and dynamically updating a set of performance management dashboards. In less than 4 months with an agile team (1 DW Architect, 1 Data Scientist, .5 BI Architect, .5 Mobile Architect & access to the client's subject-matter-experts) we designed and deployed a robust application that is revolutionizing the business of higher-education.
Performance for ingest & load times, statistical model execution, mobile device alerts/write-backs, and dashboards response times all measured in seconds or less. In my experience this raises the bar on the other platforms I've worked (and I've worked on most of them).
As for migrating the BW-tables from traditional RDBMS platforms to HANA IMDBMS? With the Rapid Deployment Solutions (RDS) approach, migrating BW to HANA is a short and relatively simple tactical exercise. Out of the box, the load and query performance is many X faster (mileage will vary depending on deployment). Then you have the opportunity to optimize the underlying analytic and calculation views to extend functionality and improve performance of your BW info-cubes and reporting.
SAP has already starting migrating the more intense/complex OLTP transactions to read and commit updates to the ERP tables that have HANA underneath them. They are seeing positive results. Why would you do this? Simple performance lift is one key reason. The more compelling reason is you will start to realize the benefits of IMDBMS supporting the hybrid workloads of OLTP and OLAP against a single integrated database design. Yes, the need for the split of OLTP vs OLAP into separate eco-systems is on the path towards obviation as IMDBMS eliminates the performance constraints which forced the need to split OLTP & OLAP workloads out to begin with.
SAP's Hardware partners are coming out with scale-out reference architectures to leverage HANA's parallelism. This on top of the high compression ratios (10X plus) and innovative temperature-controlled archiving solutions from 3rd party software partners is opening up a capacity planning model for scaling on HANA while providing a compelling overall (OLTP & OLAP eco-system) TCO.
The visionary enterprises are seeing the value proposition of moving to a platform that enables ultra-low latency OLAP and OLTP applications while significantly reducing the resources and level of effort to design and maintain these applications. Less effort because you don't have to over-engineer the data models, ingest layers and query SQL in order to squeeze out marginal performance gains. You don't have to peel off subsets of data to run the complex multi-pass statistical scoring models for fear of dimming the lights on other workloads. That means more accurate scoring algorithms and more agile plan, test. do cycles.
You can wait, but you may end up wondering why you did as you look at your competitors' taillights. I highly recommend taking a good look at the platform, get out of the box, find a compelling use-case and map out the business outcome potentials before you decide to wait and see.
