Uma coisa a lembrar é que o SharePoint não manipula tabelas grandes (2000+ registros) bem - O desempenho vai para a porcaria.
Eu também acredito que qualquer indexação personalizada em tabelas desaparecerá, embora a indexação simples permaneça.
Para minha surpresa e alegria, li que um administrador pode importar (quase diretamente) um banco de dados do Access 2007 para um site do SharePoint. Automagicamente, o banco de dados é transformado em listas e visualizações com alguma pesquisa de tabela lançada em boa medida. Com o Access 2007 instalado na máquina cliente, até mesmo os formulários e o que não podem ainda ser reutilizados.
Para mim ... isso parece bom demais para ser verdade.
Alguém realmente faz isso? Com toda essa boa notícia, onde estão as coisas ruins e as armadilhas para isso. Dependendo do tamanho do banco de dados, isso não seria como "atrapalhar os trabalhos" no banco de dados do SharPoint?
O Sharepoint é muito bom para lidar com listas de dados "simples", basicamente - mas não é tão bom se seus dados são altamente relacionais. O Sharepoint manipula campos de pesquisa, mas nunca será tão strong quanto o Access ou um aplicativo de acesso a dados. Então, se seus dados são essencialmente uma lista, então o Sharepoint pode ser uma solução viável, caso contrário você precisa procurar em outro lugar.
Talvez seja melhor migrar seus dados diretamente para o SQL Server, talvez até mesmo para o mesmo servidor que hospeda os bancos de dados do SharePoint. Você pode usar o Access como um front-end para isso. Este é provavelmente o seu primeiro passo mais fácil.
Se você não quiser dar acesso a todos os usuários yoru, então você pode criar um aplicativo da web asp.net ou um aplicativo do Windows para lidar com o acesso a dados e distribuir isso para seus usuários.
Eu posso te dizer porque eu não fiz isso. Certamente, presume-se que, quando um de meus clientes deseja implementar o SharePoint, o aplicativo de acesso existente possa ser movido diretamente para o SharePoint. O que eu tive para fazê-los entender e mostrar a eles é que, quando você implementa o sharepoint, seu fluxo de trabalho muda e é possível alterar as razões pelas quais você tinha o banco de dados de acesso em primeiro lugar. O que acabamos fazendo é importar algumas das tabelas como listas e reformular tudo para aproveitar os fluxos de trabalho do sharepoint.
Como acontece com qualquer migração, primeiro verifique se faz sentido manter o status quo antes de você simplesmente descartá-lo. As migrações são o momento de reavaliar o processo comercial para garantir que ele aproveite a nova tecnologia.
Você está lidando com o MOSS, nunca se esqueça disso. Não pense por um minuto que vai correr tão bem quanto você gostaria. Teste-o e certifique-se de verificar tudo por si mesmo e não confie na campanha de marketing deste produto.
Eu rotineiramente movo dados entre os sites do SharePoint 2007 e o Access 2007. Na verdade, a exibição "Editar na Ficha de Dados" nas listas usa o Runtime do Access no SharePoint 2007, onde o 2003 usou o Excel.
A lista de interações do Access com o SharePoint no site do Office deve fornecer você é uma boa ideia de quão bem integrados os dois são.
Dito isto, alguns dos avisos sobre o SharePoint não ser um banco de dados relacional são verdadeiros. O SharePoint não é o Access. Os dois existem por um bom motivo. No entanto, muitos bancos de dados do Access que armazenam pequenas quantidades de dados ainda se beneficiariam de uma interface da Web estão prontos para serem importados.
Eu recomendaria o sql server express ou o sql server se você tiver uma instalação já licenciada. O acesso pode agir como um frontend para um banco de dados; se bem me lembro, é chamado RDP (remote data project), que permite conectar a um backend sql e utilizar todos os recursos do Access gui. O SharePoint nem chega perto de suas capacidades e você terá uma dor de cabeça para gerenciar. Existem assistentes para atualizar para o projeto RDP, eu fiz isso no passado (acesso 2002 eu acho) e funciona muito bem e você pode usar tsql completo, não acessar sql.
HTH, Chuck
Eu ainda não tenho os pontos para adicionar comentários (newbie para SF), mas acredito que Mike T esteja entendendo mal a resposta do SQL Guy Chuck - Você pode manter seu front end do Access e apontá-lo para um SQL Slower :) back end . Você pode ter o melhor dos dois mundos - a GUI do Access com a integridade, escalabilidade e desempenho do SQL Slower.