Skip to main content
Question

Concerns of Transition from Quickbase to PowerApps


Forum|alt.badge.img+2

Hello fellow builders,

I'm writing this post in hopes someone can help provide insight or personal experience into a pending decision my company is wanting to make. For context, I'm a certified builder and have been for about 5 years now and I'm not against moving away from Quickbase.

My company wants to move away from Quickbase and into Microsoft PowerApps. Their main reasoning is, no surprise, money. They say, "Power Apps can do everything Quickbase can do." And that the cost is already included in our license with Microsoft and is far cheaper. From my understanding though, it is regarding a version that is far from the capabilities of Quickbase and that if we wanted more funcitionality that rivals Quickbase it would end up costing us the same (if not more) in the long run.

Our Quickbase license is on a transaction-based model. We use about 3 million reads a year and support about 3,000 users. Mind you, a decent amount are not consistently using the platform, but there a few enterprise-wide applications we use that they need access to.

From what I've seen of Microsoft Power Apps, it's not that impressive. To be fair, there is probably a lot to it I haven't seen. But I think it is reflective of a company (Microsoft) who has many different platforms/applications they support and profit off of; compared to Quickbase whose sole focus is their low/no-code platform.

Here is where I see it from a pros/cons standpoint regarding moving from Quickbase to PowerApps:

Pros:
- Easier integrations with SharePoint and other Microsoft tools. Currently integrations are not possible for our company due to multi-factor authentication (MFA) issues.
- In at least the short-term, it would save us a decent amount of money.
- It is one less license cost we need to negotiate around.
- Consolidates the end-user experience to another Microsoft product (i.e. Outlook, SharePoint, OneDrive), irrespective of how I feel about those products.

Cons:
- From how I anticipate Microsoft to adjust their pricing, I believe the short-term savings to be negligible when you factor in the internal resources required to move our 100+ apps to PowerApps in the next 3 years.
- Quickbase a far superior training platform and avaible education resources to support our builders through the company, enabling more nimble solutioning.
- Quickbase has a far more established/robust community of support when problems are encountered. My opinion on this is because their platform has been around for 20+ years where as PowerApps is relatively new.
- Our company does not have a good change management track record, so I'm sketpical of a successful transition to a new system for both our builders and our end-users. The impact would add to the additional hidden costs associated with such a transition.
- We currently have no reliable 3rd party vendors for PowerApps, whereas we have a couple for Quickbase.
- We currently have <5 PowerApps builders in the company compared to 20-30 Quickbase builders.

- While we have integration issues with Microsoft, Quickbase does allow us to establish a service account (i.e. a department inbox) as a user, whereas Microsoft does not allow this.

- Puts more control into IT's hands, versus our builders; which has a record of slowing down solution/enhancement implementation.

Thank you to those who took/take the time to read this and respond. I'm hopeful to hear your thoughts and maybe this post will help someone else down the road facing a similar dilemma.



------------------------------
Thank you!
Curtis
------------------------------

This topic has been closed for replies.

MarkShnierYou
Forum|alt.badge.img+24

I have a lot of thoughts and would be also happy to talk one on one. I have no personal experience with PowerApps, but I have seen benchmarking studies done by Quickbase.  

My understanding is that Power Apps is not at all an end user tool.  There are studies which your IT manager might buy from Forrester or Gartner, or which your Quickbase Account rep can provide and it's likely that Power Apps is not even on the Low Code Quadrant chart.

So that means that instead of having departmental Subject Matter Experts (SMEs) who arose organically and became Quickbase Ninja Developers, you are back to the old model where IT owns and develops all the apps, and you have the classical multi years long backlog to get anything programmed.   Believe me,  I.T. does not want to have that responsibility back.  Their job should be to vet and endorse Quickbase, provide training and security guidelines, ensure common files in Quickbase have a single source of truth, (For example like the "Employe Master" and many other files which naturally you do not want siloed and duplicated data) data and then to some extent stand back and let the power users SMEs develop the apps.

Organizations today need to be agile.  Department Managers will not wait for a 2 year backlog or a "sorry we are on hold for 3 years while we re-program in Power Apps".  So what happens?  You get back to the world of point solutions popping up all over the place and also back to "Excel Hell" as a tracking tool.   Free trial downloads and relatively low cost per userid and the next thing you know to organization is full of Monday.com type apps all over the place and with no controls at all from IT, so no security of the data and honestly barely any awareness by IT that these point solutions are multiplying out there like rabbits in the wilds.  Duplicated data silos all over the place.

You say you have 4-5 power app builders.  I bet they are all male and I bet that 50% of your Quickbase Ninjas are women.  Why is that ratio so different....? We can have our own theories, but maybe women Quickbase developers arise though the SME path organically out of Departments and they may hence have a knack for understanding user needs.  But with a hard core Power Apps builder programmer you may need to pair them up with a Business Analyst SME who will write up the detailed specs for the projects and then iterate back and forth with testing and then getting user feedback.  Whereas with a Department SME / Quickbase Developer, it can be more of an all in one package of the BA and the Developer being the same person.  So what is the extra cost of of those Power Apps builders?  They will probably be way more expensive per headcount than your home grown SME Quickbase Developers who arose organically, as opposed to have to have been "recruited" into the company,  and the Power Apps builders will need to be paired up with BAs, so perhaps double headcount.

Another thought is that yes, a saving of maybe $750K a year looks good on some bean counter finance person's resume after they move onto to other company.  But if you have 3,000 users it must be a large company which has Billions in sales.  Perhaps  $2.912 Billion in revenue in 2023 if I'm guessing correctly.  What is the cost of that loss of agility and loss of centralized control by IT?

The last thing I will mention is that well there has been a pattern of Quickbase increasing their prices, there is also a significant commitment to make Quickbase better. Lately we've had new Table reports, Pipelines, new Forms, (and in the fall they will support Mobile properly) and at Empower they are surely going to announce more very big things as they like to hold back and make splash announcements at Empower.  You Quickbase Account rep can probably provide insight on what those may be if have you sign a non disclosure agreement.  So you need to compare the modernization with what Power Apps is doing.  Now I have no idea what that is, but it might be nothing to improve the end user experience UI. 

Lastly, no one wants to lead a project that will simply peeve off 3,000 users to "maybe" save a relative pittance for a $2.9 Billion dollar company.  That is a thankless job for sure.



------------------------------
Mark Shnier (Your Quickbase Coach)
mark.shnier@gmail.com
------------------------------


Forum|alt.badge.img+19
  • Qrew Captain
  • March 11, 2024

I have a client that moved from Slack to Teams for internal messaging.    A simple Quickbase webhook had to become an entire series of PowerApps integrations that never worked correctly.   The complexity of MS compared to both QB and Slack is daunting.



------------------------------
Don Larson
------------------------------