The Covid-19 pandemic has changed how we think about everything, from grocery-shopping to commuting to travel. The world has changed and likely things will never be the same.
With millions of people in the US alone working from home full-time for the first time, many companies have been forced to re-think their future strategies. Many are wondering how important is it to have the limitation of all the employees in a fixed physical location, with the cost and scarceness this brings, when they have proven they can run many parts of their companies remotely and even have improved productivity.
And once you realize that physical location isn’t a limitation, why not take these benefits even further and gain access to a huge talent pool with lots of benefits?
Talk to us if you’re ready to test these benefits with some of our near-shore resources based in Costa Rica. What’s there to lose?
Microsoft Access was the first database engine built specifically for Microsoft Windows, back in 1993. With this it became the main database engine in the late 90’s and was widely popular in the early 2000’s.
One of the things that made Access very popular was that it shipped with Visual Basic for Applications (VBA) and this made the creation of basic applications very easy. That, combined with the prevalence of Microsoft Office made it a very good option for single user applications.
Outgrowing the platform
As it often happens with software, many of these applications grew much more than planned or became critical for the business. Maybe they started as small tools, probably replacing some manual process, but over the years turned into hard-to-maintain, complex systems.
A truck manufacturing company that exported their catalog from their AS/400 mainframe as an Access file, built a few forms to create orders and then shared this file across all the dealerships that ordered stuff from them (probably a handful at the beginning but hundreds of them in recent years).
A government agency that started using a small Access DB to record measurements from a few rain stations and ended up storing data from hundreds of sites with rain amounts, river and lake levels, hours of sunshine, temperatures and others, along with their corresponding reports and charts. In the end the app was the main tool used on a day-to-day basis by a dozen employees.
The solo coder who created a few models to predict the scores of NFL games, started selling the weekly data and continued by using similar models for NBA, MLB and NFL.
What exactly is the problem with these apps?
Well, if you’re in this page you probably already know some of the issues with these apps. But here are some of the most common nonetheless.
Having an Access database or application is not necessarily a bad thing. As of this writing, Access is still supported, as well as VBA. On that side, you should be able to continue using this platform for the foreseeable future.
The problems typically come from the lack of options once these apps go beyond the single-user or intranet application. At some point you’ll also need to worry about the size (the maximum size for an Access DB is 2GB).
For applications that rely on VBA there’s also the problem of maintaining the business logic. First, it’s hard to find VBA developers (or developers that think adding VBA to their resume is a good idea). Second, VBA doesn’t make it easy to integrate with newer technologies (like consuming RESTful APIs or using gRPC).
The other (and probably most common) issue, is when the business needs change and multiple users need to access the database. Access has a shared mode, but it has limitations and still assumes users have direct access to the database. This might also add some security concerns. Accessing the application via Internet or in multiple offices just makes things worse.
In the end, the problem is not Access, it’s just that it’s being used for something it wasn’t designed for.
How do I fix it?
Now, some of these applications can be easily replaced by a new application, or maybe even some COTS offerings. In other cases the business logic might be too complex or the app too custom to be easily replaced and needs to be maintained, re-written or migrated.
Nowadays there are many alternatives to Access, both for storing data and to build basic line-of-business applications. Some of them free, some of them built into other popular offerings and most of them very accessible and easy to integrate.
Some of these options include:
Microsoft Sharepoint (And the many offerings that are built on top of it)
In some other cases it might make more sense to use a fully fledged development platform (.NET or Java) and use a full-blown database engine. That’s always an option.
In any case, you’ll need to prepare a good plan for it, including:
How to migrate existing data?
Will the users require re-training?
How will the new platform be tested to verify all the business logic is there?
Will the new platform enable new business models?
Are there any limitations of the new platform (e.g. will all users require permanent Internet connectivity to use it)?
Which features from the new platform do you want to incorporate as part of the modernization?
Will my existing developers be able to continue maintaining the applications?
As you can see, all these are important questions with no single right answer. It will all depend on what your existing Access application or database does, who your users are and what are the long term business goals. What’s important is that we can help you answer them and create a full modernization plan that ensures you can continue focusing on your business instead of the limitations of your technology.
Modernizing an application is not always a straightforward decision; after all, the application is working as it is and probably your team is already busy with their day-to-day responsibilities.
My application isn’t legacy, is it?
A big issue with legacy applications is that it’s not something that happens from one day to the next. Most likely the application was started with up-to-date technologies and little-by-little those tools and platforms were deprecated or stopped being popular.
A very interesting article by Jose Aguinaga back in 2016 does a great job of putting the evolution of technology in perspective. Even though the article is a few years old, it is as true today as it was when he wrote it.
A developer who wants to start a new project today after working on an existing product for a few years will find that most of the technologies he’s familiar with have changed, in some cases disappeared or simply fallen out of grace in the community. There are many reasons why this happens, but in most cases one can expect the new technologies to provide certain benefits or advantages over the technology they replace.
Seeing the speed at which all technology changes, the likely answer is yes, your app is legacy. This, however, doesn’t necessarily mean you need to run and upgrade to the latest and greatest (if you did probably you wouldn’t do anything else).
When is modernizing the right answer, then?
As with any non-trivial question, the answer is “it depends”.
Each company and application is different as well as the speed of the evolution of the different technologies. You probably don’t have to upgrade your application from .NET Framework 4.7.2 to 4.8, but if you don’t, when is it time? when version 5 comes out? Maybe version 6? What if Microsoft stops releasing new versions of the framework and move all their development to .NET Core? Should you upgrade then?
There are, however, some factors that can speed up the decision process, for example:
New personnel. Hiring a developer that knows the latest technologies should be pretty easy, but good luck finding a COBOL or a VB6 developer.
Security. Is your organization OK with your applications using technologies that will no longer receive security patches?
Platform support. For how long will your users accept that your application works only in Internet Explorer?
Sales. The app might work and your existing users might be happy with it, but will new clients say yes to your old desktop application when your competition has a responsive web-site, mobile notifications and all the new bells and whistles?
Those are just some of the indicators that we see in our clients’ apps that point to the need of modernizing the app.
What do I do now?
I’m glad you asked.
First of all, let’s talk about your needs and see what’s the best way to work together. We’ll help you create a tailored modernization roadmap and not only bring your company to the present (future?), but also create a plan that prevents you from falling into this technical debt again.
File -> New… select the latest technology everyone is talking about and begin with a blank slate.
In reality though, most developers end up working maintaining existing applications, some of them going back several decades. If you don’t believe me, just look at the job openings for Cobol developers in Indeed. I bet you there isn’t a lot of new projects started in Cobol nowadays.
Now, don’t get me wrong, there’s a reason some of those technologies have lasted as long as they have. However, finding new developers or adding new features taking advantage of the latest technologies is very hard.
Modernizing can have many faces, you can always re-write the entire application, you can develop a new one by gathering new requirements, you can use automation tools to help you with the process, maybe you can buy a commercial solution to replace part of the functionality or you can refactor part of the application and begin using new technologies where it makes sense.
Every one of the choices has advantages and disadvantages, but one thing is certain, we can help you make a decision and implement it for you.