If you have Cognos and are moving to – or thinking about moving to – Power BI, you’ll find yourself facing a significant – and largely manual – hurdle: getting key reports rebuilt and accessible in the new tool. You can significantly shorten migration timelines by automating the process.
In this on-demand webinar, we showcase our two accelerators that help catapult Cognos migrations to the finish line. You’ll get a demo of the Report InstaMigrator, which lets you move Cognos reports with just a few mouse clicks. (Shazam! You’ll feel like a superhero). We’ll also demo the Migration Assistant, which programmatically inventories and organizes Cognos content for an optimized migration.
Come see what it takes to successfully move from Cognos to a new platform:
- The challenges of migrating from Cognos to a new platform
- Migration approaches: manual migration vs. using accelerators
- The ease and benefits of using Senturus migration accelerators
- Pros and cons of each approach
Steve Reed Pitman
Director of Enterprise Architecture and Engineering
With a career that spans 20-plus years and clients from the Fortune 500 to Inc. 5000, Steve is adept across many facets of analytics including data architecture in physical, virtual and cloud environments. He transitions easily from the server room to the boardroom, speaking the language and understanding the priorities, risks and complexity that accompany the selection, implementation and operation of technology in fast-moving enterprises.
Senior Business Intelligence Developer
Denis is a seasoned Business Intelligence Developer with more than ten years of experience. He blends technical expertise with a deep understanding of business needs, delivering user-friendly reporting tools and dashboards that inform key decisions in areas ranging from Information Security to Government Services.Read more
Welcome to today’s Senturus webinar on accelerators for Cognos Power BI migration.
Happy to have you all here.
As always, thank you for joining us.
Quick overview of today’s agenda.
We’re going to do some quick introductions, talk just broadly about the challenge of migrations and some of the options for approaching migrations.
We’ll talk about what a manual migration looks like and what an accelerator assisted migration looks like.
And then we’ll do a both a demo and an intro to our migration assistant tool and our new report Instant Migrator Tool.
We’ll wrap up with a little overview of Senturus and as I said, we’ll do Q&A at the end with quick introductions.
I’m Steve Reed Pittman, Director of Enterprise Architecture and Engineering here at Senturus.
If you’ve attended many of our webinars, you probably know me as the guy who’s usually doing the beginning and end of the webinars kind of emceeing things.
Today, I’m actually going to be presenting.
In addition to doing this part, I’m also joined today by Dennis Abando.
Dennis is one of our top consultants here at Senturus.
He’s a seasoned to be eye developer with over 10 years of experience.
He combines technical expertise with a deep understanding of business needs.
Dennis is great at delivering user friendly reporting and dashboards to inform key decisions in areas ranging from information security to government services.
So Dennis, thank you for joining me here today.
And before we launch into the real details of today’s presentation, just want to run a couple of quick polls to kind of understand where everybody is at.
Our first poll is what is your best guess of the total number of reports in your Cognos environment got less than 500 all the way up to more than 5000.
And so I’ve got a bunch of answers coming in here so far it looks pretty well distributed across all of those options.
I’ll keep it open for a little while, seem to be falling.
One comment I will make is I you’ll often discover that you think you have fewer reports in your Cognos environment than you actually do and a lot of the time that’s because there’s a bunch of stuff hidden in individual users my folders that you just don’t see.
If you’re a Cognos admin, you know, it’s difficult to see that information.
I’m going to go ahead and close the poll here and share the results out so everybody can see.
So again it’s looking for the most part you’re all in the 2500 or less at least in terms of reports that you can see that’s good to know, nice range there.
I’m going to go ahead and stop sharing this and let’s jump on to the next poll, which is what are your plans for Cognos, your future plans for Cognos?
If you’re attending today’s webinar, it’s probably because you’re planning to move or are already moving from Cognos to Power BI.
So do you plan to keep Cognos for the long term?
We do find organizations that intend to just run Cognos and Power BI in parallel.
Are you planning to migrate off of Cognos in the next couple of years?
Are you planning to migrate off of Cognos quickly next 12 months or are you already in that process And we again, we find organizations in all of these stages.
All right, I’m going to go ahead and close out this poll, share the results.
So again, a little over half of you are planning to migrate in the next couple of years quarter of you planning to keep Cognos for the long term.
And down here at the bottom, we got about 10% of you who are already into that process and let’s launch into the webinar.
So going to talk a little bit about the migration challenge just in general, anybody who’s ever done a migration knows migrations could be big, hairy, scary activities.
And the first question is, you know, where do I even start, right?
I mean, you first you got to figure out how many reports are out there.
And again, it’s easy to see what’s in Team Content.
That gives you a pretty good idea of what’s out there.
But you also need to figure out how much stuff is in Users, My Content folders.
And even once you know how much stuff is out there, how do you identify the stuff that doesn’t need to be migrated?
Because often there’s a lot of stuff that you can simply throw away or leave behind.
And how do you prioritize the content that does need to be migrated?
And even beyond that, a lot of customers say, well, would I be better off just starting from scratch, right?
Am I better off just throwing that out completely and just rebuilding everything from the ground up?
And that’s a valid question.
And sometimes that does make sense.
So what does a migration look like in general?
So this is just going to be kind of a broad picture.
The first thing you do in any migration is you need an inventory of your content.
You need to know what’s out there, right?
What do we have of everything that’s out there?
What is actually being used?
What isn’t being used and what’s redundant because you often find copies of copies of, copies of reports out there.
So even though you might have, say you have 3000 reports in your environment, if you dig a little deeper you may find that a bunch of those are just copies of each other and you really have far fewer unique reports than you may think.
So once you’ve got your inventory, then you need to start planning your migration.
And there are some key questions to ask so that you don’t waste resources during your migration #1 what can be eliminated?
You want to identify any content that’s unused or that’s a duplicate because obviously you don’t want to move all that stuff across if it isn’t actually needed.
That’s just a waste of time, energy, money, what can be consolidated?
So it’s also common to find that there are a bunch of reports that are very similar to each other.
And if you can identify the reports that are similar, maybe they just have a different filter, you know, slight tweaks to the data that’s included.
You can often take several reports that are similar and consolidate them into a single report to also make your migration cleaner and smaller.
And there’s a question of what can be streamlined.
So over time, especially if you have Cognos, you’ve probably had Cognos for a long time and you get package bloat, you get report bloat.
And what you find is over time, there are portions of packages and reports that often are.
They’re kind of orphaned.
They’re still in there, but they’re not actually referenced by anything.
If you can figure out what pieces are not actually being used, you can leave those out when you do your migration again.
This simplifies migration, makes for a cleaner target platform and also saves you time in the process.
Once you’ve done your planning, obviously you have to execute the migration and you have to figure out who’s going to do the work and what expertise do they need to do.
We have resources already who are subject matter, subject matter experts in Cognos?
Do we have people who are subject matter experts in Power BI and how long will it take for them to do the work?
And those are very elastic questions.
It depends a lot on the complexity of your content.
It depends on the approach you choose to take for your migration.
And obviously it depends on what level of expertise you have in house to actually do the migration work.
So what are the ways to approach migration?
One is to do it manually and you know, old school, this is what we had to do, my first ever migration project, I think we had about 20 people down in the trenches working on that migration because we had to do everything manually.
We had to grab that inventory.
I had to look at everything by hand.
We had to do all of the content movement by hand.
We had to rebuild everything in the target environment by hand.
Manual migrations are a heavy, heavy lift.
It’s time consuming.
You have to open up and catalog each report and package by hand to figure out what’s in there.
You do have the benefit of being able to use the Cognos audit data to take a look at usage.
So you can at least get a sense of what reports are most popular and that can help you kind of prioritize, you know what sequence you want to move things across in.
Then you have to decide from all that what content you’re actually going to migrate.
And then manually you go in and you rebuild that content from scratch and Power BI.
And because there’s often a lot of similarity in Cognos reports and just in terms of overall structure in an organization, there’s a lot of just repetitive redundant effort if you’re having to rebuild things by hand.
Instead of manual migrations today, you can do an accelerator assisted migration.
And this is really the key subject for today’s webinar here at Senturus.
We have a couple of tools that are designed to be migration accelerators.
And so today, we’re going to be talking about the Migration Assistant and the Report Instant Migrator.
The Migration Assistant solves the challenge of doing your Cognos inventory by programmatically cataloging your entire content store.
So instead of going in and manually having to look at everything, figure out what’s there, figure out the structure of your reports, figure out the structure of your packages, Migration Assistant actually pulls all of that in preprocesses.
It gives you an easy way to view and analyze all of the aspects of your content so you can do smarter migration planning in a lot less time, and so we’ll do a demo of Migration Assistant here in a bit.
We’ll also go through the Report Insta Migrator, which is a newer product.
The Report Insta Migrator actually automatically will create Power BI project files for you from your existing Cognos reports and packages.
So it’s a very quick way to move stuff over Report Instant Migrator also includes GitHub integration.
It generates a GitHub repository which allows you to do source control, helps with project tracking and enables you to do DevOps implementation for your deployment of Power BI reports.
And Dennis is actually going to be doing our Instant Migrator demo here a little bit.
So accelerating the migration process, we’re going to talk about the Migration Assistant first.
And the Migration Assistant, because of its structure, is really suitable both for planning and for execution when you’re doing some manual work in the execution side.
And I’ll talk a little bit about why that is as we go through the demo.
But essentially what the Migration Assistant does is it programmatically decodes and inventories all of the reports and packages that are in your content store, stores all of that information in a structured database.
And that database includes key details including the data sources that are in use, the lineage, the relationships and also pulls in the auto data regarding usage.
So it gives you a really broad perspective on where and how your content is being used and also what the structure of that content is.
So how does it help?
Well, number one, it gives you comprehensive, accurate data to do your migration planning and execution.
It’s much less error prone than the manual approach because it pulls everything in, make sure you don’t miss anything, and gives you a bunch of ways to slice and dice that information to make the decisions that make sense for your organization.
It also helps you identify quick wins, so lowest hanging fruit is always a good thing to go for when you’re doing a migration.
So the Migration assistant helps you figure out which things will be both the easiest to migrate and the and have the most impact.
It helps you out.
So going back to some of the things I discussed earlier about just the general migration considerations.
The migration system does help you find unused and duplicate reports.
Those are all candidates to be eliminated.
Don’t need to migrate those.
Helps you identify similar reports so you can decide which things make sense to consolidate.
So you might be able to go from 10 reports down to one in the new environment.
It also helps you identify the unread, unreferenced portions of your reports and packages.
And that can help you with streamlining and simplification as you go through the migration process.
So let’s do a demo of the Migration Assistant and switch my screen here and the Migration Assistant actually ships with two Power BI workbooks.
I have these published out to the Power BI service for today’s demo, but you can also use these locally in Power BI Desktop.
So the two workbooks.
The first one is what we call the Assessment Workbook and this is really useful during the initial stages of planning your migration.
And what the Assessment Workbook does is it provides you with broad overview of how things are being used, how complex they are to help you make decisions about what should and should be migrated and help you decide how to prioritize them.
I’m going to jump around a bit here in the interface I’m going to start, well, let’s talk about the overview here on the homepage.
So homepage here gives you just a summary.
And incidentally, this data is from one of our local content stores primarily has great outdoors content in it.
Of course, because those are the standard samples, I can’t show you actual customer data.
So this content store is a lot smaller than your content store obviously would be.
That gives you a nice idea of what is provided in the migration assistant.
We can see we’ve got a little under 400 reports here in our sample content store, 19 different models, 31 users and we’re running 28 schedules.
But we also break out the objects by typing your content store.
So we can see we’ve got 400 reports, 28 schedules.
We’ve got some explorations, some data modules, some updated files.
There you can see report executions.
You get a sense of what the most popular reports are in your environment.
We also measure the complexity of your reports and categorize them so we can see not too many complicated reports here in our environment.
You would likely find a fair amount of low complexity reports, but then a broader range of medium and some high complexity reports in your own environment.
Jump over to the model complexity here.
So this section evaluates details about your published Cognos packages.
I’m going to go ahead and sort by the model complexity score because that’s the most interesting thing to me on this page.
So here we can see and this is essentially the relative complexity of your models to each other.
So by doing this we can see the most complicated package in this environment is the Go Data Warehouse analysis package.
If I Scroll down to the bottom, our simplest one is this COG Report SP, which is a very simple packet that’s probably just a single query pulling data.
That’s probably a stored procedure since somebody has an SP in there.
So this page gives you an idea of how complicated your models are.
That also gives you a bunch of detail about what’s in them.
We can see this model has 381 query subjects, uses 71 different tables.
We can see it only uses a single data source, about a lot of tables from that data source, so there’s a lot of rich information available to you in here, and you can also see the path to where that package is located.
Over here we’ve got a four quadrant chart for the models.
This is really useful for figuring out the lowest hanging fruit.
So I’m going to start up here on the top right low complexity and high usage.
So any environment where you have simple models that are heavily used, those are great first candidates for migration.
They’re going to be quick to migrate.
Lots of people use them.
The business sees benefits very quickly.
And so often you’ll want to start with things that show up at this quadrant, excuse me.
Then you may want to go from there to the high complexity, high usage.
We don’t have any of those of this content store.
These are going to be harder to migrate because they’re complicated, but because they’re high usage, again, they’re likely to be high value to the business.
Down here you can have you’ve got low complexity and low usage.
These also easy to migrate because they’re low complexity, but probably not as much of A priority because they’re not as heavily used and high complexity and low usage.
You might want to ignore these if you can, simply because they’re going to be a lot of work to migrate and because they’re not heavily used.
These often would be the last ones that you would consider if you’re doing an actual migration.
All right, I’m going to jump to some of the report information here.
So we’ve got a report complexity page.
This is similar to the model complexity.
It gauges the complexity of your individual reports.
Let’s make sure this is really sorted properly.
There we go.
So again, this is relative complexity of all of the reports in the content store, so it gives you a sense.
This all Data Containers is our most complicated report.
You can see where it’s located and there’s a little bit of other information about how many times it’s been executed, whether it’s used by any report views.
Just a lot of useful info about your reports.
I’m going to jump to the user summary view here.
So this gives you a view of all the users in the system, how many reports they’ve run, when they last ran things.
And so this is really useful for seeing kind of who your most active users are.
And I’ve already got this sorted correctly.
So we can see Todd Schumann here.
If you’ve been to many of our webinars, you probably know who Todd Schumann is.
He runs our Cognos installation and upgrade practice and he uses our environments a lot.
So no surprise that Todd is here at the top of our report executions or you can also see users that are in the environment but haven’t actually executed any reports.
So this just gives you a sense of user activity.
You can also get a view of the schedules that are running.
Now often schedules in a Cognos environment can be tied to business processes.
They can be tied to key daily reports, monthly reports.
Often these are things that go to executives or sales teams.
So often schedules are really, really important in a Cognos environment, and this gives you a sense of what schedules you have out there, how often they’re running.
It can help you make decisions also about which things you might want to migrate sooner rather than later in your environment.
We also have a page here called V11 Object Summary and this is an overview of objects which, you know, V 11 isn’t new anymore, but there were object types that were introduced beginning in version 11 Cognos.
Things like data modules, explorations, Jupiter notebooks, yeah, so we capture that information here and you can see in this environment we’ve got 180 or 155 data modules.
I don’t have any data sets here, no Jupiter notebooks or uploaded files, but it gives you a way to view some of those newer object types.
We also summarize custom SQL in your reports.
Now everybody knows you should never ever use custom SQL in a Cognos report.
And everybody knows that custom SQL is used heavily in Cognos reports.
So this gives you a view of all the reports in your environment that you have SQL in them.
It shows you the length.
So we can see like this report up here has a pretty long streak of SQL in it.
This one just has probably a simple select, but this gives you a way to kind of get a sense of what’s out there that is using custom SQL.
These also, in fairness, are likely to be easier to migrate because they’re probably relying much less on any of your actual Cognos packages and more on the sequel that’s in there.
So that would actually be easier to replicate in Power BI.
Last but not least, we’ve got a comparison summary here.
This does a full cross comparison of all of the reports in your content store and gives you a sense of which things are similar, which things are not, and helps you kind of figure out and prioritize the best way to tackle your migration.
So that’s the Migration Assessment Workbook.
I’m going to go over quickly to the Assistant workbook, which is more of the implementation oriented workbook.
Again, we’re going to jump into the report Instant Migrator after that, which Dennis will take care of to show you how you can do some of the automatic trend translations and conversions of your Cognos content.
So Migration Assistant Workbook.
So this workbook provides much more fine grained detail about individual reports packages and is really most useful when you’re actually executing your migration.
So often that assessment workbook will be used by a manager or project lead for the migration to kind of map out how you’re going to do your migration.
This assistant workbook I can help a developer quickly figure out what are the things that I need to replicate to find recreating stuff in Power BI.
I’m going to go through this pretty quickly because I want to make sure we have time for Dennis to do his Insta Migrator demo, but the Assistant workbook.
Again, it gives you some of the same information that you saw in the previous workbook but at a much finer grain of detail.
So we can see here all of the reports in our content store we can sort by last run.
I’m just going to leave it here on the R.E.M.
count so we can see this crosstab with prompt page.
Isn’t has been the most frequently executed report in this environment.
As you click on these and view a specific report, you’ll see that the data updates dynamically and this also shows us.
So there’s a crosstab with prompt page that actually appears in two different places here.
So I’m going to go ahead and choose this one and when you select a report you can see these are the data sources that are used by that report.
These are the underlying tables that are in use.
So all of this gives you key information for being able to recreate your report in the target environment.
On the reports page here this provides you really detailed information about a specific report.
So in Cognos, you would have to open this up in in what I still like to call Report Studio, even though it’s no longer called Report Studio.
You can open up your report in the reporting interface within Cognitive Analytics and you can see this information by clicking around.
Or you can export the XML and look at it in an XML editor if you’re into that kind of thing.
But you can also use our Migration Assistant.
If you do that, you get all the information you need right here.
You don’t have to go digging for it.
You can see all the queries that are part of this particular report.
So you can see the containers on the page, the types of charts that are in use, details about the query items, what expressions are used to pull the data, what filters are there so you know what’s coming in, see the underlying data sources.
Just a wealth of information about your report.
We’re here on the executions page.
Again, you get a more detailed view of what’s been executed, how frequently, and when.
It also shows you which users have executed a particular report.
So this can also, you know, if you’re looking for reports that you know, for example, what reports do some of our key executives like to run.
You can get that information here, which can really drive some of your decision making about which reports to migrate first.
And last but not least, we’ve got relationships.
This really gives you details about your underlying packages, and so if you’ve got you know if it has a lot of organizations do.
If you’ve got one like a big hairy package that gets used for a bunch of stuff, you know, basically a kitchen sink package.
This is a great way to be able to navigate some of that without having to go into Framework Manager and or without even really having to understand Framework Manager.
You can just get a sense of what the data model looks like, which can help your Power BI experts do the modeling work on their side.
All right, So I’m going to jump back to my deck here and we’re going to talk a little bit about the Report Insta Migrator and then I’m going to have Dennis take over and give us a demo of the Insta Migrator.
But first, I just want to talk a little bit about what the Insta Migrator does.
So as I said earlier, it is effectively does batch migration to the Power BI report format.
It takes existing cognitive reports and packages, generates Power BI report structures from them.
We leveraged the Power BI project file format for agile development and that’s a relatively new thing.
Power BI used to be a bunch more closed, but now there’s actually a Jason based and folder based structure for Power BI called Power BI Project Files and we leverage that to do these conversions.
The Instant Migrator also creates a GitHub repository and it sets up a folder structure and creates GitHub issues or all of the reports that are converted.
So anything that we aren’t able to automatically convert because there often will be complicated expressions that can’t be easily converted to DAX.
Things like that will create GitHub issues, which are kind of like trouble tickets in GitHub so that you have a record of what needs to be addressed in a particular report, and Dennis will show a demo of that here shortly.
So how does it help?
Well, number one, it shortens the migration timeline.
Both of these tools do that right.
They save you time because there are things that you would otherwise have to do manually that are being done more automatically by these accelerators.
Also, it enables source control.
So once you’ve got these reports and a Power BI project file, if you have developers doing additional work on them, you can actually track version changes.
Because all of this is in GitHub, allows you to track progress.
Also gives you the opportunity to integrate it with your DevOps pipeline if you want to use a DevOps approach to deploying your reports.
And with that, we’re going to do a demo of the report Instant Migrator.
Dennis, I’m going to turn it over to you.
All right, Thanks, Steve.
So the goal here today is to show you just how quickly and easily we can migrate A Cognos model and a couple of reports from this Cognos environment and into this Power BI workspace that we created report, instant migrator workspace.
I’ll just walk here quickly through the components that we will be migrating.
The first one is this record package, so one package and we have a couple of reports.
They’re not too complicated, but just to kind of show you sort of the ease and speed of reported semigraders.
Our first report is the two page record report.
On the first page we have two list objects, one with album names and the second one with artist names and album counts.
The second page is just going again just going to be a single list with general names.
Moving on to our second report, it’s literally called the simple record report, which is basically just a data dump of our FM model.
So to do that I can go ahead and show you report and semigrader.
Here it is, and the first thing that we’re going to do is connect to a local database where we’ve extracted the Cognos Content Store.
And after we connect to the database, we’ll be taken to a list of all of our packages in our Cognos environment.
So let’s go ahead and search for that first record package and the next screen is going to again be a list of all of the reports and for, you know, a lot of you, this could be hundreds if not thousands of reports that we have here for you to be able to select.
Again we’ll search for our simple record report and our two page report and click continue and we will be taken to a conversion confirmation screen which basically says we’re about to convert 1 package and two reports.
And the conversion will actually output the associated files to a local folder on your machine which I’ve already set up.
So let’s go ahead and convert and it’s already done.
So here we go.
You can see kind of how fast report and some migrator can handle the job here.
And let’s go ahead and open up that local folder and view the generated files.
And here we are.
So here’s our chosen output folder.
We have two separate folders for the data sets and the reports.
So let’s go ahead and go into our data set and we have our record package.
And as Steve mentioned, you’ll notice that these are PBIPE Power BI project files which let us basically access the underlying code for our Power BI components.
Let’s go ahead and open this up, all right.
And when we first open up these models and reports, there will be a few errors that that that show up.
But all we need to do is basically apply these changes and we will refresh the data set and you’ll notice off to the right in the data pane, we already you can already see our Album table, which is effectively the presentation layer in Cognos.
So if we expand that out, we have successfully imported the presentation layer of our record package.
And if we take a look at the Model view, I did mention that this Album table is the presentation layer in Cognos.
In Framework Manager, you’ll know that you know basically there are three layers here, the presentation, the business layer and the physical layer that include all of the relationships between, you know, your fact table and your dimensions and all of those have been preserved.
So you can see here that you know we have our artist ID relationship and also our genre relationship to our genre dimension.
And here is our business layer.
And by default the physical and the business layers have been hidden in Power BI because similarly to Cognos, we would really only want the end user or the report developer to see and build reports off of this physical layer.
So we’ve hidden the business and the physical layers and we can actually we’re actually ready to publish this this data set.
So let’s go ahead and save our changes and we’ll select our report in semigrader workspace.
And it has successfully been published.
Let’s open up the workspace.
You can see that we now have our Power BI data set.
Let’s go to the workspace.
All right, so here’s our reported to migrated workspace with our record package, semantic model, and the report artifacts.
Both successfully published a Power BI service, Again, pretty easily and with really with just a few clicks.
So let’s go ahead and look.
Take a look at our reports.
Now back to our output folder.
Go to our reports.
Let’s open up our simple record report.
And again, as these reports are opening up, they have not yet been connected to the record package data set and as it should lag us to do that.
So we’ll all we need to do is go to get data, we’ll go to our data sets and here is our record package data set, we’ll connect.
And so I think I just need to do one thing actually in the workspace.
So when publishing out these new models we do, we do just have to re authenticate the credentials here.
Let’s go ahead & in.
Let’s go ahead and refresh again and here we are.
So you know in part of the conversion process the in Cognos we had list objects and so now these have been converted into the appropriate Power BI table visual.
We have our album name and you know basically the, you know the same, the same exact output that we had in Cognos.
So let’s go ahead and publish this out again to the workspace to show you how easy it is to publish this out, right.
And here we are.
So now we’re in Power BI service and we’ve successfully published out our first report.
Let’s go ahead and take a look at our second report.
Now our two page record report, which is slightly more complicated.
There we have two pages and a couple of visuals on that first page, a couple of table visuals, all right.
And again we will get that error, but all we need to do is connect to our Power BI data set and there we go.
So here’s our first page with our two list objects that have been converted to table visuals and our second page with our genre table.
And again, let’s go ahead and quickly publish this out to Power BI service.
All right, Let’s go ahead and open that up and confirm that it’s all there and it is.
So pretty quickly here, you know, you can see just how fast and how easy it is that report.
Instagram Migrator makes the process for automating the conversion of Cognos content to Power BI and there are a couple of other items here we wanted to discuss is that part of the of the challenge for converting these reports is taking basically Cognos expressions and converting them to DAX expressions.
So if there are any you know specific expressions that report into Migrator can’t figure out then you will be notified that there that there were any of those.
And in cases like this, it would help to have you know somebody with some Power BI experience to sort of help with that process of translating these expressions to DAX.
And also as we continue to sort of develop the, the mapping and translation feature of power of reported Semigrator, then you should see less and less of these over time.
And so the last thing we’ll do here is we’ll take this entire conversion and we’ll create a repository in GitHub and all you need to do that is to give a repository name called this support Insta Migrator Webinar, go ahead and publish that.
And what it’s basically doing is creating a repository based off of this folder structure and the and the files that were created in the conversion process.
So you’ll see here shortly that once we open up GitHub, we’ll see a very similar here we go structure of our repository.
So if we go into issues, oh so here we go.
So if we have our data sets and our reports here and if we go into issues, you’ll see that each component that was that was converted will have an issue.
So we have one here for our two page record report, one for our simple record report and one for our record package and if we go into pull requests and open one of these up.
We can just give you a quick preview of what we were mentioning about the PBIP Power BI project file type which basically gives us access to the underlying code that that builds, you know these data sets and reports.
So, you know, again, pretty quickly here, we’ve been able to, you know, convert and migrate A Framework Manager Model 2 reports, publish them to Power BI service and then also create a, a GitHub repository.
So now you’re all set up as Steve mentioned, if you wanted to take, you know, a DevOps approach to your Power BI implementation.
So thank you.
Thank you, Dennis.
Sorry, it took me a moment to get unmuted there.
Let me go ahead.
Can you hear me?
So let me take over the screen sharing here.
Switch back to my view.
Also just a reminder for everybody, because we’ve had a couple of questions in the Q&A panel, both about help with migrations and about the presentation.
So if you do want to copy the presentation, you can find that link in the webinar chat.
You can also go straight to Senturus.com/resources and find a copy of it there.
Also, K Knowles from our sales team has been posting her link also in the chat.
So if you do have questions and need help with your own migrations, reach out to Kay.
You can schedule time on her calendar through calendar and that link is also out in the chat.
So here at Senturus, we’re here to help.
If you’re doing a migration, you know migration is something you at least hopefully only need to do one time.
But we do migrations all the time.
So we’re here to help and not just with the tools that we’ve discussed today, but we can help with team, you know, supporting your team with additional resources.
We can help just in an advisory capacity to figure out what is the best way to tackle your migration.
We offer ad hoc services to maximize the ROI on your migration and we have deep experience on both sides of this fence.
So if you need a Unicorn who knows Cognos and Power BI, we’ve got them when you need them.
And we can advise you on the best mix of tools of people to get your migration done and done successfully.
And you can contact us at [email protected] type migration into the subject and we’ll get back to you very quickly.
And again, you can also schedule time directly on K’s calendar through the link that’s out there in the chat window.
A little bit of wrap up stuff here before we go into the Q&A.
As always, you can find tons of additional resources on our website.
We’ve got product reviews, we’ve got tips, tips and tricks, lots of blogs.
We have past webinars, both recordings of the webinars and the decks.
So check all of that out at Senturus.com/resources.
Couple of upcoming events next week.
We’ve got a webinar on Microsoft Fabric architecture or architecture.
Microsoft Fabric has been getting a lot of play in the media, and we’re going to dig into what Microsoft Fabric is, how it’s useful, how it’s different, how it isn’t different from the tools that preceded it.
That’s next Thursday, December 7th.
We’re also going to be conducting an in person workshop for Microsoft.
Fabric, date and location are still to be announced on that, but if you are interested in attending an in person workshop, let us know at Senturust.com/events.
A little bit of quick overview about Senturus if you don’t already know.
We are all about modern BI, making it accessible, you know, helping it, helping you accelerate your BI initiatives.
We cover the whole, yeah, But we’ve been in this business for a long time, 22 plus years, 1400 plus clients, 3000 plus projects.
Some of you might even be parts of some of the companies you see here.
So we’ve been doing this for a long time and we’re still small enough to offer personalized service, but we’re large enough to cover all of your BI and analytics needs.
And with that, we’re going to jump into some of the Q&A.
There are a bunch of questions that have come through here, so we probably won’t get to all of them in today’s session.
Again, however, if we don’t get to your question, we’ll follow up with you afterwards and we’ll actually post a log of the questions and answers for the webinar.
So let’s see here.
I’m just going to kind of go through.
I also have the benefit of having my development team here in the background, so I’m going to draw on them for some of the answers, but I will do some.
I’ll do what I can to answer the questions that I’m able to.
So let’s start off here at the very beginning, looks like Vaishali asks what would be the main reason for a company to migrate from Cognos to Power BI.
And of course, there are lots of reasons companies choose to migrate.
But one of the biggest reasons we find is that companies don’t want to pay for cognitive licensing anymore.
You know, Power BI is included in a lot of Microsoft stuff, right?
I mean, if if you’re using MS365, you basically have the basics of Power BI for free.
And so the difference between a free modern BI platform and a much more expensive platform that that can be a real driver for doing a migration.
Of course, a lot of companies have a huge investment in Cognos and it’s not trivial to migrate.
So on the flip side, a reason the companies decide to keep Cognos is that the effort to do the migration just seems like too much and they’d rather just maintain their existing Cognos environment.
So that’s just one reason that companies choose to migrate.
Another reason is simply for kind of a more modern experience and new features something that’s more cloud oriented and all of these things are reasons that companies choose to go to Power BI.
Oh I will say yeah hi.
I think that they might have been alluding to also kind of when to start from scratch or when to bring it over.
And a lot of folks who have lost kind of their intelligence, their, their team, you know, who understands their models are looking to for help to kind of unravel that logic.
That’s one reason also that they’re looking for some help on the migration.
And of course if it’s a embedded product or OEM type product, that’s another one that we’ve seen frequently external users or whatnot, there’s a whole bunch.
So just reach out to us, we can discuss them.
Yeah, you know, that’s a great point because so many organizations that are running Cognos have been running Cognos for a long, long time.
And you know, if some of your real Cognos experts or the people who built your packages that are heavily used are no longer in the organization, all of that knowledge has walked out the door.
So and that can be a a real reason to move off to a new platform and have your current modelers build, go to the new stuff.
Let’s see what else we’ve got here.
In the question panel, there was something broad.
I want to kind of address the broad questions 1st and then we’ll get into more detailed items like gosh, more and more questions are coming in all the time.
Let’s see what I’ve got here.
There’s a question about what kind of So RAM asks what kind of Power BI licenses are required to publish reports out to the Power BI service.
So that depends on what kind of Power BI licensing you have in your organization.
The, the basic Power BI service is free.
So what you saw in my demo here where I had the migration Assistant workbooks published in the service that’s using the basic free version of the Power BI service.
So that’s you know that’s very easy to do.
However, that is not like a production level environment.
So if you’re using Power BI Premium in your organization, which does require separate licensing, you would basically have to have Power BI Premium to publish to A to a production level environment.
And I know there are some newer licensing details with Power BI Premium per user.
I I’m not a licensing expert on Power BI, so I can’t say too much more about that.
But those are kind of the basics.
In terms of the Power BI licensing, there is a question here about complexity.
And so I’m going to reach out to the development guys here because I know we have a pretty fancy algorithm under the hood and we do.
It is customizable for your specific environments, we’ve customized that algorithm for some customers.
But Bob, I don’t know if you can maybe just talk a little bit about how we gauge complexity.
Sure, Happy to.
Can you hear me?
Yep, Yep, sounds great.
So on the model side, we look at a combination of factors, including things like the data sources, the number of query subjects and query items used, any filters you have in place, all sorts of those aspects of the of the model that could influence complexity and come up with the complexity score there.
And then similarly on the report side, we look at the number of queries, the number of pages and number of objects on those pages.
And then things like do you have a bunch of custom sequel written on that page?
Do you have additional filters on that page, all those components go into those complexity scores and then as you alluded to earlier, we can fine tune those for clients.
So you know if you have a very unique Cognos environment, you’ve done some unique things in there and certain factors in your reports would drive more complexity than others, then that’s we can work with you to fine tune that a bit.
A couple of broad kind of Cognos and Power BI questions here.
So Alex asks which version of Cognos has the migration feature and is there a separate migration button.
So one thing to understand is these tools are not directly in your Cognos environment.
So Cognos doesn’t have any built in capability for migrations.
These tools pull the data from your Cognos content store to do the migration work, so it’s not native to Cognos.
Alex also asks, why are you encouraging the migration to Power BI?
Are you planning to discontinue Cognos?
So I’m going to answer that in two ways.
I mean, one, Cognos of course is really IB Ms.
And no, Cognos is not being discontinued by any means.
IBM continues to invest in Cognos and release new versions and add functionality and Cognos is still very popular.
Most of you, if you’re attending this one, are probably are still using Cognos.
So Cognos is not going away and here at Senturus, we certainly aren’t stepping away from Cognos.
We still do a lot of Cognos consulting and that’s been the core of our business for many, many years.
But what we have seen in recent years is a greater uptick in Power BI usage and the desire to migrate off of Cognos to Power BI.
That’s what led us both to develop these tools and to offering today’s webinar.
That’s another question here about refreshes.
Let me see if I can find it.
Yeah, everybody is just firing away with questions here.
So I’m losing track of my he goes, oh, so the question Michael asks, can a refresh be set up in Power BI server on the semantic model?
So once you have migrated your reports and deployed them either to a Power BI server as Michael asks here, or out to the Power BI service, I believe that all of the refreshes, like all of that is different from the Power BI side, right?
So Bob, keep me honest here, but I think that essentially as a Power BI admin you control those refreshes, you know from the Power BI administration side of that, that’s correct.
And if they’re talking to data sources back in your like an on Prem or your private cloud environment that would then need a Power BI gateway so that it could securely communicate back.
But yeah, that’s all scheduled through the Power BI service.
We’ve also got a question here about GitHub.
Oh, it just popped off my screen.
I can find my way back to it.
All right, I I’ve lost track of it here on the list.
But somebody was asking about can instead of using GitHub, can you use a local git repository or do right now?
Does the Insta migrate or just generate A repository out on GitHub there?
That question right here, but I know I saw it.
Oh, sorry, go ahead, Archer.
Yeah, sorry I answered that one, Steve.
No, right now we only support GitHub.
Thank you for that.
We talked about complexity.
So again everybody, we’ve got a lot of questions coming in here, so I apologize that we’re not going to be able to get to all of them.
There’s a question Gene asks about whether these tools are installed on a clamp machine or the Cognos server or in the Ms.
So let me just talk a little bit about the tools and some of the underlying requirements because we didn’t talk about that before.
So #1, the Migration Assistant under the hood is actually, it’s a two piece tool.
One piece is the extraction tool that pulls the data out of your content store and your audit store processes.
All of that generates what we call the Migration Assistant database that contains all of that information.
That’s a Java application that you typically will install on a server in your environment.
And then it also includes these Power BI workbooks which again can be used in Power BI Desktop or they can be published out to the service.
The Report Instant Migrator also is a stand alone tool.
It’s a Windows application.
It doesn’t live on your Cognos server, but both of these tools are essentially client side tools that you run directly when you’re working on your migration.
One other note about the Migration Assistant.
We do recommend when you’re using the Migration Assistant to pull data out of your environment, especially if you have a heavily used Cognos environment.
We really encourage using offline backups of your content store and audit store because of course you don’t want to interfere with performance of your production environment while you’re pulling all that data out.
And if you have a really large content store, as many companies do, it can take a while for the migration assessment to actually get all of that data and process it.
You know, we do a lot of heavy lifting automatically under the hood there, so often recommend doing that with offline backups.
All right, we’re down to the line here.
Let’s see if we can do one more question before we wrap up.
We talked about refreshes, we talked about complexity, talked about why companies choose to migrate.
You know, actually one thing I want to address that we talked about at the very beginning is why not just throw everything out and start from scratch?
And you know, a lot of companies contemplate that.
And in reality, often the best approach can be some of both.
And there’s nothing wrong with deciding to do a hybrid approach to your migration.
Sometimes it makes sense to say, you know what, we’re going to throw out a whole bunch of this stuff.
It’s just not worth it.
But we’re going to figure out what the top 10 or top 20 or top 100, you know, whatever makes sense for your organization.
You might want to use tools to expedite the migration of just a key subset of your content and then throw everything else out and let your organization, you know, let your individual team members build what they need as they need it going forward.
So as I said, we’re here to help advise you and assist with migration across the board.
And you know, reach out to Kay if you’d be happy to talk to you more about the details and help you figure out what makes sense in your environment.
All right, so we’re back to the end of the hour here.
So we’re going to wrap up.
Thank you everybody for attending today.
It’s always great to have you here for our Senturus webinars.
If you do have additional questions, you can reach out to us [email protected].
You can give us a phone call also contact us through our website.
So thank you again.
Thank you Dennis for helping out with the Insta Migrator demo and we hope to see all of you again at a future Senturus webinar.
Thank you and have a great day everybody.