Printable Version of Topic

Click here to view this topic in its original format

UtterAccess Forums _ Access Q and A _ List Of Access Migration Services / Support Consultants

Posted by: Bucca Sep 10 2019, 01:19 PM

Hello UtterAccess,

Is there a list of consultants anywhere of companies that migrate existing Access databases to a SQL or Oracle back end and then provide support for this back end as well as consulting services and support for the still used Access front end? I work at a university and I designed a database that tracks our space. It has 40,000 space records with a number of attributes linked to each space record e.g. occupants, space types, function codes, etc. It also loosely "connects" with other systems with exports of data into those systems.

Some feel it may be time to migrate this to a more robust back end but this begs the question what about support for the front end that would still exist and some suggest finding a "canned"system to does the space management and where they provide all the support for both the front and back end.

Thus, I'm doing some research to find out what kind of services do what I briefly described above. I don't think my system is big enough nor does it have a lot of users to look for a canned system so the migration seems a stronger possibility.

Is anyone aware of a sound solid company that has been around and does this as their core business?


P.S. Eventually this will need to go out to bid and use our state laws and regulations but until that time I am free to communicate and do research about companies. A some point a Request for Qualification, Information, Proposal, etc. will be generated an then things become much more formal.

Posted by: DanielPineault Sep 10 2019, 01:25 PM

No, not per say, but you can contact most Access MVPs and/or VIPs from this site, many provide such services.

Posted by: GroverParkGeorge Sep 10 2019, 02:13 PM

We can't really maintain such a list here for a couple of reasons.

One would be that it might imply endorsements of those on the list, which we can't really offer.

That said, of course, feel free to reach out to any of the regular contributors here at UA to see if any of them have time and interest. I know several do make their living doing exactly what you describe.

Keep in mind, though, that if you intend to put out an RFP, some developers might be hesitant to invest in a lot of discovery with you knowing that they'll end up bidding against other developers later.

Posted by: tina t Sep 10 2019, 02:20 PM

I designed a database that tracks our space. It has 40,000 space records with a number of attributes linked to each space record e.g. occupants, space types, function codes, etc. It also loosely "connects" with other systems with exports of data into those systems.

Some feel it may be time to migrate this to a more robust back end

40k records is in the small range for an Access table, depending on what record size, whether external files are being stored, etc. before you go too much further, suggest you make a list of the specific improvements/advantages you want to get from migrating to SQL Server, or another RDMS. and then find out if you will actually see positive results in those specific areas by migrating.

from reading here at UA and other forums over the years, i know that there are numerous good reasons to move your data from Access to SQL Server etc; so i'm not in any way saying you shouldn't. just saying you should have a clear understanding of what you will get, and possibly what you won't, by making the move.


Posted by: PatHartman Sep 21 2019, 10:47 AM

40,000 rows is tiny in the database world. You should be pushing the million row mark or more than 1 g of overall size before considering converting the BE. On the other hand, even a small app would work better with a RDBMS BE if the number of concurrent users exceeds 50.

Keep in mind that if your app was created without regard to client/server principles simply converting the BE from Jet/ACE to SQL Server might make the app too slow to be usable and you will also have to rework the FE to regain the speed you got with Jet/ACE.

Typically, once you convert to a RDBMS BE, the database DBA becomes responsible for managing the production database. The developer would only ever have access to the test database and would require interacting with the DBA to effect schema changes after the initial implementation. The consultant would manage changes to the FE and work with the DBA to promote those changes to the production environment.

I don't post here often (I contribute in other forums regularly) but I am a former Access MVP. I might be able to help or at least convince you not to do the conversion at this point unless there is something I don't know about your situation.

Posted by: Jeff B. Sep 21 2019, 06:20 PM

I'll jump on the same bandwagon... why? What do you expect will be better ("better") about having the data in SQL Server or some other more fully-featured RDBMS?

I ask to gain some insight for what's pushing the change...

Posted by: WildBird Sep 23 2019, 02:22 AM

I can think of security of data would be better in a better system, but agree, could be more hassle with little to no benefit if it hasnt been designed with SQL Server or other RDBMS from the start. Likely to be slower, or need a bit of rework - pass through queries, stored procedures on backend etc.

Posted by: PatHartman Sep 23 2019, 03:34 PM

Just FYI, I design all apps starting with Jet/ACE linked tables and only upsize when the schema is stable. The reason for this is that most of my clients are large enough to have IT staffs that control access to the database server. If I want to create a new database or modify an existing one, I need to provide scripts to do it and wait my turn. In some companies, I can't even work as my own DBA in the test region. So, in order to not be delayed or become an annoyance to the DBA's, I don't involve them until I actually need to start testing with the actual BE. What you can take away from that is that I almost never need to use pass-through queries or stored procedures to work with SQL Server or other RDBMS. There are some differences between the two environments so I have to choose options that work for both or in some cases write code that determines which type of BE I am using. I do have one app that is sold to the public and the buyer can decide whether to install the SQL Server BE or the ACE BE and the FE will work with either. That app is the only one in production that actually contains a small section of code where I had to use one method for ACE and a different one for SQL Server because I couldn't tell in advance which BE the client would choose and I was not willing to maintain two separate code bases. In all other cases, the app, in its production implementation uses either an ACE BE or a SQL Server, DB2, Oracle, Sybase, etc. BE but doesn't switch on demand.

Except in very rare situations, coding for client/server works just as well with an ACE BE but not vice versa.

Sometimes my apps never reach the need to upsize and other times they get upsized before being moved into production. In any case, it takes rarely more than an hour to use SSMS to upload the linked tables and data and "convert" the app to using SQL Server as the BE. In the case where I've made some mistake, I go back to the ACE version and fix that until the upsize goes without any errors.

My first introduction to Access was with a project for Readers' Digest (in the early 90's with Access 2.0) where I discovered that I could update DB2 tables on our IBM mainframe with my Access app. I became a believer and Access has been my tool of choice ever since.