Because Oracle Reports has been given an official end-of-life date, it’s now more important than ever to evaluate your reporting strategy. This month, we’re tackling the problem head on in our Oracle Reports blog series.
Why is a Reports migration strategy important?
The process of migrating your reporting and analytics tools involves many decisions. You want to cut out unnecessary steps and tools as much as possible and reach your stated goals with confidence. A Reports migration strategy is important in order to make sure your organization achieves those stated objectives. There are measurable benefits to the platform you’re moving toward, and there should also be a set of clear goals for moving off of legacy tech.
There are several scenarios you might recognize as goals for a Reports migration. Each scenario will have a different solution pathway:
Reducing licensing costs
Freeing up legacy infrastructure
Staying on supported versions
Meeting compliance standards
Post-acquisition merges
Reducing redundancy
For example, if you are strictly cutting costs, a one-to-one replacement project with a short timeline is going to be more acceptable than an exhaustive overhaul of how you interact with enterprise data. A short-timeline approach or a total transformation broadly represent two extremes that you might take during a migration process. Will an extensive overhaul benefit your organization with new insights and better data? Or will you benefit most from a quick, decisive technology switch that saves costs and lets you get on with daily business?
What planning should go into a reports migration project?
In any case, if you don’t plan correctly, your organization could significantly over-invest in technology that is not an appropriate fit. Or you could spend time solving problems that mattered years ago instead of anticipating the solutions you will need tomorrow.
It’s time to be proactive, not reactive. Here are the approaches you could take for your Reports migration:
Approach 1: Manual Conversion
This involves a human and business oriented understanding of how your reports help you do work. Interviews with consumers of your reports, as well as with admins who create them, will be a vital step.
Upsides
The upside of this approach is that you may innovate in the process to make your reports reflect current needs.
Downsides
The downside is the amount of time it takes to conduct these projects when everyone involved probably also has a day job. The time and costs involved are apart from the migration redevelopment effort itself, which is a necessary (and expensive!) part of a manual conversion.
Approach 2: Semi-Automated Conversion
Semi-automated conversions involve code analysis software that can parse your Oracle Reports and generate those reports one-to-one within a new technology. Each report will still need some expert revision, but the process moves must faster.
Upsides
The project is contained; there is much less risk of failure. Semi-automated conversions take less time and the costs are easier to control. They require less thought work and hand-holding from the reports users, admins, and IT, as the expectation is the output of the old reports is the standard that the conversion must meet.
Downsides
You aren’t necessarily doing the reflection on where your reporting can create opportunities for your business. Your organization may be limited in the amount of technologies you can convert. That’s not to say these things are impossible, but they’re not an inherent part of a semi-automated engagement. These are typically a component of a larger transformation process.
Approach 3: Automated Conversion
In short, “automated conversions” are a bad idea. You can trust us: there are no magic bullets. Someone promising full automated conversion does not have your enterprises’ interests at heart. They’re trying to treat your needs as if they were identical to everyone else’s. Their straight-jacket approach will likely be more expense and leave you with fewer options.
Upsides
Are there any? In our objective opinion, these engagements rarely produce valuable outcomes.
Downsides
Using these tools generates more technical problems than were originally assessed. The promise of a turnkey solution with no forethought or expert analysis makes your situation out to be simpler than it really is. Your reports matter to your enterprise. They deserve to be treated as important as they are. At best you’re kicking the can; at worst you’re creating more problems than you started with at the beginning of this project.
Who should take ownership of the project?
This is an important point to consider. Should reporting continue under IT or should it move to a more business-oriented business group? Who takes ownership of the project, provides leadership and guidance, and establishes the budget?
Because data is such a key piece of digital transformation, all applications and users that touch reporting in many enterprises are moving into the sphere of new digital service groups and away from traditional IT. IT may administer the systems, but the services group drives direction, creates reports, and assists with applying information. This is as a result of business become more tech-savvy.
If you’re convinced that data will help you create new revenue and your executives are embracing digital transformation, move reporting to a digital services group. You will have more control over the process and an easier time with budgets and accountability toward results. This is less because IT is inflexible and more because the needs around data are rapidly evolving and must move closely with the business.
However, if your reports are supporting stable processes and functions within the organization, they can stay with IT where you can rely on IT to manage the new solution cost-effectively.