Migracja bazy Access do aplikacji webowej krok po kroku

Kiedy Access przestaje wystarczać

kilka osób edytuje bazę naraz i pojawiają się blokady rekordów albo komunikaty o konflikcie zapisu,
plik na dysku sieciowym się uszkadza i trzeba go naprawiać albo odtwarzać z kopii,
pracownicy z domu lub z terenu łączą się przez VPN, a baza działa przez niego bardzo wolno,
nowy komputer ma inną wersję Office i część formularzy przestaje działać,
logikę w makrach i VBA rozumie jedna osoba, której odejście zatrzymałoby dział.

Jeśli dane trzymacie w arkuszach, a nie w Accessie, ten sam problem omawiam w tekście z Excela do aplikacji webowej.

Co przenoszę z pliku Access i jak

Element w Accessie	W aplikacji webowej	Uwagi
Tabele i relacje	tabele w bazie na serwerze z kluczami i ograniczeniami	przy okazji poprawiam typy pól, na przykład daty zapisane jako tekst
Kwerendy	filtry, widoki i zestawienia liczone na serwerze	kwerendy o nazwach typu Kwerenda1 opisuję razem z osobami, które ich używają
Formularze	ekrany w przeglądarce z kontrolą poprawności pól	układ zbliżony do starego, żeby zespół szybko się odnalazł
Raporty	wydruki i PDF generowane przez aplikację	odtwarzam te, które firma faktycznie drukuje lub wysyła
Makra i VBA	logika w kodzie aplikacji, objęta testami	każde makro najpierw spisuję, bo część okazuje się nieużywana

Backend piszę w Pythonie, w Django. Dlaczego ten framework dobrze znosi aplikacje z wieloma tabelami i formularzami, wyjaśniam na stronie aplikacje w Django. Pojedyncze makra, które mają zostać w Excelu, to osobny temat: makra VBA na zlecenie.

Etapy migracji bez zatrzymywania pracy

Spis zawartości bazy: tabele, relacje, kwerendy, formularze, makra i to, kto czego używa. Nieużywane obiekty trafiają do archiwum.
Próbny import danych i porównanie liczby rekordów oraz sum kontrolnych ze starym plikiem.
Pierwszy moduł w aplikacji, na przykład kartoteka klientów i zlecenia. Reszta działa jeszcze w Accessie.
Kolejne moduły i raporty, za każdym razem z ponownym importem świeżych danych.
Dzień przełączenia: ostatni import, a plik Access zostaje jako archiwum tylko do odczytu.

Dane po latach pracy w Accessie

Stare bazy mają powtarzalne usterki: tego samego klienta wpisanego na trzy sposoby, puste pola, które powinny być obowiązkowe, kody ukryte w polu uwag, rekordy osierocone po usunięciu klienta. Przed importem pokazuję listę takich przypadków i ustalamy, co poprawiam automatycznie, a co przegląda ktoś z zespołu. Reguły czyszczenia zapisuję w skrypcie importu, więc przy każdym próbnym przebiegu działają tak samo.

Budżet i to, co go podnosi

Baza z kilkoma tabelami, formularzami i raportami dla jednego działu to zakres modułu od około 8000 zł netto. Gdy Access obsługiwał kilka działów, magazyn i rozliczenia, nowa aplikacja jest raczej lekkim ERP, od około 15 000 zł netto. Najwięcej pracy zwykle dokładają makra i nietypowe raporty, a nie same dane. Szerzej o wymianie starych programów piszę w tekście modernizacja starego systemu firmowego, a o terminach na stronie ile trwa tworzenie aplikacji dla firmy.

Najczęstsze pytania

Czy mogę zostawić Access jako interfejs, a przenieść tylko dane?

Da się podłączyć Access do bazy na serwerze i bywa to dobry krok przejściowy. Nie rozwiązuje jednak pracy zdalnej bez VPN ani zależności od wersji Office na każdym komputerze.

Co z danymi historycznymi z wielu lat?

Przenoszę je w całości. Przy dużych ilościach najstarsze rekordy mogą trafić do archiwum tylko do odczytu w tej samej aplikacji, a wyszukiwanie po nich nadal działa.

Czy aplikacja zadziała na telefonie?

Działa w przeglądarce, więc także na telefonie i tablecie. Najczęstsze czynności projektuję tak, żeby dało się je wykonać na małym ekranie, a rozbudowane formularze zostają na komputer.

Czy po migracji dostanę kod i bazę?

Tak. Kod jest w repozytorium firmy, baza na serwerze, do którego masz dostęp, a struktura tabel jest opisana. Nie zależysz od jednej osoby tak, jak przy starym pliku.

Migracja bazy Access do aplikacji webowej: dane, formularze i raporty