u/bitmetric

Some time ago, I went through two data visualization books by Willard C. Brinton, published in 1914 and 1939.

What surprised me most was how familiar much of the advice still feels.

Simple bar charts were often preferred over more elaborate alternatives. Misleading axes were already a thing. 3D visualizations were criticized. Heatmaps were being used effectively. And there was plenty of discussion about how presentation influences whether people actually understand the data.

The big difference was the tooling. Creating a Sankey diagram could involve manually arranging a thousand strips of paper, while a 3D visualization might literally require plywood and a saw.

I collected some of the more interesting examples here:

https://www.bitmetric.nl/blog/old-school-data-visualization/

It made me wonder: which data visualization “best practices” do we think are modern, but are actually much older than we realize?

We’ve been involved in quite a few conversations and projects around moving Qlik environments to Qlik Cloud, and noticed that most of the discussion tends to focus on moving the apps.

In practice, that’s usually not the difficult part.

The things that tend to require more thought are security rules vs. spaces and roles, Section Access, task chains, gateways, NPrinting/reporting, licensing, extensions, and what you actually want to clean up rather than migrate.

So we tried to put the whole process into one practical guide:

https://www.bitmetric.nl/blog/qlik-cloud-migration-complete-guide/

It covers QAMT, what does and doesn’t migrate, QlikView vs. Qlik Sense migrations, governance, licensing, gateways, common mistakes, and the first 90 days after go-live.

We’re particularly interested in experiences from people who have already done a migration. Anything you think we’ve missed, got wrong, or underestimated?

Apparently, people still search for Qlik cracks, serials and keygens.

So we did the only logical thing and built a landing page for it, complete with a proper 1990s-style cracktro.

There is no actual crack, of course.

The serious part is that high Qlik costs are often caused by licences, usage and contract terms no longer matching the way the environment is actually used.

But mostly, we just wanted an excuse to build the intro 😉

Most people think about apps when they think about backups. Makes sense. But a Qlik Cloud environment is more than apps: data connections, automations, spaces, permissions, tenant settings, reload tasks, themes, extensions.

We wrote up how we think about this practically: what belongs in a backup, what you can and cannot restore via the API, and why thinking about restore deserves as much attention as the backup itself.

Curious what others do here. Do you have a backup setup in place, or do you rely on Qlik's own platform availability?

Disclosure: we are Bitmetric, a Qlik-focused consultancy. The article is on our blog.