VirtualKansas
asked on
Best Practices for migrating an Access Database to SharePoint 2013 Online
This will spawn multi-part series of questions, but let's respect the rules and start with one...
We're at Enterprise 2013 online. We have a project database that is well formed. Beyond simply migrating the tables up to SharePoint and using the traditional front end (split design), we'll want users to do data entry using InfoPath forms.
So, before I get ahead of myself the question is: Can you guide us to a best practices method for this migration that allows users to do "data entry" in either traditional access front end and/or InfoPath forms?
Assumes that migrating the current tables up to SharePoint is way to go...
We're at Enterprise 2013 online. We have a project database that is well formed. Beyond simply migrating the tables up to SharePoint and using the traditional front end (split design), we'll want users to do data entry using InfoPath forms.
So, before I get ahead of myself the question is: Can you guide us to a best practices method for this migration that allows users to do "data entry" in either traditional access front end and/or InfoPath forms?
Assumes that migrating the current tables up to SharePoint is way to go...
ASKER
Yow. OK, then. I would love to think that our little database is simple. The origin is roughly Y2k so doubt new data types exist. I inherited the database of course and there were poorly named fields that have since been resolved (i.e. using "?" in field names.)
The relative ease of developing SharePoint forms using InfoPath is my main attraction. Again, our data is relatively simple and project life cycles are finite. We do more with documents and document libraries than actual data entry. Again, this is the attraction to SharePoint and using one interface for the entire project in this case, SharePoint.
Would be easy for me to over simplify and say SharePoint lists are fine. I have connected lists to Access using Lightning Tools and have developed some pretty good web service type renderings of what is essentially list data. Am only reasonably confident that lists will be OK in limited experience.
Let's assume SharePoint lists are sufficient, for now. A better question is then how to manage what is essentially the one and only primary key of the Access design. There are only ~7 tables in the design and on field in one table is the PK for whole shooting match. Does this back story change the tune, at all?
The relative ease of developing SharePoint forms using InfoPath is my main attraction. Again, our data is relatively simple and project life cycles are finite. We do more with documents and document libraries than actual data entry. Again, this is the attraction to SharePoint and using one interface for the entire project in this case, SharePoint.
Would be easy for me to over simplify and say SharePoint lists are fine. I have connected lists to Access using Lightning Tools and have developed some pretty good web service type renderings of what is essentially list data. Am only reasonably confident that lists will be OK in limited experience.
Let's assume SharePoint lists are sufficient, for now. A better question is then how to manage what is essentially the one and only primary key of the Access design. There are only ~7 tables in the design and on field in one table is the PK for whole shooting match. Does this back story change the tune, at all?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm going to close this one and split the points. Will open another to dig deeper. Warnings about SharePoint lists as tables and the end of life for InfoPath are both helpful responses. On to the next, with my thanks...
Assuming you have the latest version of SharePoint, you can start on the path to making your existing Access app an Access/Web hybrid. Once you have migrated the BE to Azure and tweaked the FE so that it works responsibly in a client/server environment, you can begin to build Access Web forms. The Web form has limited functionality but that may be OK if the Client/Server part of the app does the heavy lifting. Access web forms do NOT support VBA and so you are limited to whatever you can do with macros but they're probably better than Info Path since they are not disconnected.
That should get the conversation started.