Migratie van Access naar SQL Server
Wanneer grote hoeveelheden data moet worden opgeslagen, het aantal gelijktijdige gebruikers en prestaties parten gaan spelen, betere beveiliging en betrouwbaarheid noodzakelijk is, dan is de migratie van Access naar SQL Server de oplossing.
Op deze pagina een uitgebreide verhandeling over wat Office Programs voor uw organisatie hierin kan betekenen. Voor wat de beste oplossing voor uw organisatie en voor de door u in gebruik zijnde databases zal zijn, daarin kunt u persoonlijk worden geadviseerd.
Mooie en goede databases groeien
Microsoft Access is een prachtig platform waarin schitterende applicaties gemaakt kunnen worden. Maar die schitterende applicaties, waar goed gebruik van gemaakt wordt, zullen met de tijd groeien. Daardoor zullen ze meer bedrijfskritisch worden. Er kan dus een moment aanbreken waarin u de overweging zult maken uw Access applicatie naar een krachtiger platform over te zetten. Hiervoor kunnen verscheidene redenen zijn: de omvang, het aantal gelijktijdige gebruikers, de veiligheid, de betrouwbaarheid/stabiliteit of een combinatie van deze of andere factoren. Microsoft SQL Server is dan de perfecte kandidaat.
Er zijn echter een aantal plussen en minnen verbonden aan 'de grote verhuizing'. Daarbij komt dat de verhuizing naar Microsoft SQL Server niet voor alle Microsoft Access databases nodig is. Verder zijn er ook verschillende manieren waarop Access met SQL Server gecombineerd kan worden. Om u te helpen een redelijk goed beeld te geven, zullen we in deze verhandeling de belangrijkste plussen en minnen toelichten.
Access en SQL data structuur
Sinds de introductie in 1992 is Access een veelzijdig database platform voor zowel single-use als multi-use, waarvoor kleine werkgroepen kunnen worden gemaakt. Omdat Access ontworpen is om (door kenners) gemakkelijk te gebruiken en de toegankelijkheid te vergroten, is het nooit de bedoeling van Microsoft geweest om Access aan te merken als het meest robuuste en het meest betrouwbare database platform. In het algemeen zijn dit nu juist de eigenschappen van de applicatie waarom men overweegt om de Access applicatie op te schalen. Gelukkig bestaat er binnen Access de flexibiliteit om Access via de Upsize wizard op verschillende manieren te converteren naar SQL Server; van een snelle en kostenbesparende methode waarmee slechts de data wordt verplaatst, naar een veel duurdere oplossing waarin de applicatie volledig opnieuw wordt geschreven.
Access biedt een rijke verscheidenheid aan gegevens architecturen die het mogelijk maken om data op verschillende manieren te beheren. Daarom is bij het overwegen van een opschalingbewerking belangrijk om inzicht te hebben in hoe Access geconfigureerd kan worden; namelijk door zijn eigen Jet Engine te gebruiken of rechtstreeks met SQL Server.
Access en de Jet Engine
Erg belangrijk is te weten dat Access gebruik maakt van zijn eigen database engine, namelijk de Microsoft Jet Database Engine. De Jet Engine is ontworpen als een fileshare database die single-user en multi-user database applicaties ondersteunt tot een maximale omvang van 2 GB. Maar Access is meer dan een database: het is een ontwikkelomgeving waarin gebruikers toegestaan wordt om query's te ontwerpen, om formulieren en rapporten te maken, om macro's en visual basic code te schrijven om zodoende een gehele applicatie te automatiseren. In de standaardconfiguratie gebruikt Access de Jet Engine om de ontworpen objecten op te slaan zoals formulieren, rapporten, macro's en visual basic code. Ook gebruikt Access de Jet Engine om alle gegevenstabellen op te slaan. Al deze mogelijkheden van Access gaan echter wel ten kosten van de betrouwbaarheid (en stabiliteit), veiligheid, prestaties, etc.
Maar niet getreurd: wanneer het gaat om opschalen, is een van de grote voordelen van Access dat u de applicatie kunt herontwerpen om de reeds ontworpen formulieren, rapporten, macro's en code te kunnen blijven handhaven. U kunt ook de Jet Engine vervangen door SQL Server. Hiermee heeft u het beste van twee werelden in handen: de gebruiksvriendelijke ontwikkelomgeving van Access met de betrouwbaarheid en veiligheid van SQL Server.
Een vergelijk in vogelvlucht tussen Access en SQL Server
| Access | SQL Server | |
|---|---|---|
| Beschrijving | Een gebruiksvriendelijke database ontwikkelomgeving die query's, formulieren, rapporten en programmacode ondersteund. | Een schaalbare, betrouwbare en veilige client/server database applicatie. |
| Maximale omvang | 2 gigabytes | 1 terabyte |
| Maximum aantal gelijktijge gebruikers | 5-15 | Onbeperkt |
| Prestatie | Beperkt door fileshare model. | Alleen beperkt door hardware. |
| Betrouwbaarheid | Redelijk betrouwbaar. | Erg betrouwbaar. |
Access en Jet Engine als single-user
Standaard gebruikt Access de Jet Engine om de objectdefinities op te slaan
inclusief de gegevenstabellen. Zowel Access als Jet draaien op de computer
van de gebruiker; ook de database wordt op een lokale harde schijf opgeslagen.
Access en Jet Engine als multi-user
Zowel Access als de Jet Engine staan multi-use toe. In dit scenario draait
op de computer van elke gebruiker een exemplaar van Access (een FrontEnd)
en Jet, en is er een koppeling gemaakt naar een gedeelde MDB database (het
BackEnd dat de tabellen bevat) op een netwerkschijf.
Access, Jet Engine en SQL Server
Access staat u toe om SQL Server aan te wijzen als uw data opslag. In dit scenario gebruikt Access nog steeds de Jet Engine om query's uit te voeren, objectdefinities op te slaan, tijdelijke tabellen te managen en beveiligingsinstellingen te handhaven. Echter, alle tabeldata wordt nu opgeslagen in SQL Server. Omdat Jet een vertaalslag maakt naar SQL Server, hoeft er weinig te worden aangepast.
Gebruik maken van Access en SQL Server, zonder de Jet Engine
In dit scenario wordt de Jet Engine volledig uitgesloten. Access 2000 en hoger
biedt de mogelijkheid om direct met SQL Server verbonden te worden zonder
tussenkomst van de Jet Engine. Omdat Jet niet meer de vertaalslag maakt, moet
er meer worden aangepast.
Beslissen wanneer u gaat opschalen
Om u te helpen uw beslissing te vereenvoudigen, wordt u in deze rubriek uitvoeriger geïnformeerd over waarom en wanneer er opgeschaald dient te worden.
Erg belangrijk is te weten dat lang niet alle Access databases opgeschaald hoeven te worden. Het merendeel van Access applicaties moeten gewoon niet worden opgeschaald. Dit, omdat de kosten en de verstoring van uw bedrijfsprocessen gewoonweg niet een kostenbesparing op uw middelen zijn. Deze databases werken prima op een basis van dag tot dag en behoeven geen kenmerken als schaalbaarheid, beveiliging en 100% betrouwbaarheid.
Van alle Access databases in uw organisatie zullen er slechts enkele kandidaat zijn voor opschaling. Bovendien zullen uit de lijst voor opschaling, de meeste kunnen worden omgezet volgens de kostenbesparende methode waarbij alleen de data naar SQL Server wordt gezet. Alle functionaliteit van de applicatie zoals formulieren, rapporten etc. blijft in Access. Voor een veel kleiner gedeelte uit de lijst zal het nodig zijn om zowel de data als de applicatie om te zetten waarbij nog steeds gebruik kan worden gemaakt van Access (zonder Jet).
In de volgende rubrieken bekijken we de belangrijkste gebieden die betrokken zijn in de database planning en wordt besproken hoe Access binnen elk gebied presteert.
Schaalbaarheid
Schaalbaarheid is gedefinieerd als het vermogen van een toepassing om te werken op een aanvaardbare wijze als het aantal gebruikers of processen aanroep binnen de toepassing toenemen. Access/Jet is geen schaalbare toepassing, en schaalbaarheid is vaak de hoofdreden voor opschalen.
De maximale database omvang
Access ondersteund tot 2 GB data. Deze beperking is echter eerder in theoretische dan in praktische zin.
- Access maakt gebruik van de fileshare gebaseerde Jet Engine. In tegenstelling tot de client/server oplossingen zoals SQL Server, zijn fileshare databases niet geoptimaliseerd voor grote sets met data. Stel, een Access query moet het totaalbedrag van 10.000 facturen leveren. Dan moeten alle 10.000 facturen over het netwerk worden verstuurd en moeten lokaal de berekeningen worden gemaakt. Daarna kan pas het totaalbedrag worden gegeven. In het client/server model wordt dezelfde query direct behandeld door de server en alleen het resultaat wordt geretourneerd aan de client applicatie. Bij de grotere databases kan de fileshare architectuur de belasting niet aan.
- Jet is niet ontwikkeld voor optimale en betrouwbare prestaties bij grote database formaten. Veel installaties zullen beschadiging van data zien als gevolg van slechte netwerkverbindingen of slecht ontworpen applicaties. Deze beschadigingen komen meestal voor bij Access applicaties die de 100 MB overschrijden.
Het aantal gelijktijdige gebruikers
Technisch gezien kan Access 255 verbindingen per database toestaan. Dit is echter een theoretische grens die in werkelijkheid niet gehaald kan worden. In de realiteit wordt het aantal verbindingen/gebruikers dat een Access database kan ondersteunen, bepaald hoe goed een applicatie is ontworpen en geïmplementeerd. Een zeer goed ontwikkelde applicatie kan misschien 20 gebruikers aan, terwijl een slecht ontwikkelde applicatie met pijn en moeite genoeg heeft aan 2 gebruikers.
Helaas zijn er maar weinig Access databases echt goed ontwikkeld en goed geïmplementeerd. Dat is omdat de meeste Access databases door beginners zijn gemaakt of door ervaren gebruikers die toch de expertise en professionaliteit missen om echte, professionele applicaties te maken. Deze applicaties zijn op een bepaald moment gebouwd en er zijn nieuwe functies en data modellen 'aangeplakt' wanneer de noodzaak zich voordeed. Het resultaat is een 'totaaloplossing' die nooit aan meer dan een paar gebruikers de nodige betrouwbare ondersteuning kan bieden.
Architecturale problemen
Omdat Access de Jet Engine gebruikt voor database management, kan het per definitie niet goed schalen. Jet is beperkt tot het draaien van een enkele CPU (Central Processing Unit), terwijl de client/server applicaties zoals SQL Server, vele CPU's kan ondersteunen. Daarnaast worden Jet query's altijd op de client computer uitgevoerd, hetgeen de gecentraliseerde query/data optimalisatie elimineert die nodig is voor een schaalbare applicatie.
Betrouwbaarheid en beschikbaarheid
Als overwogen wordt tot opschalen, is betrouwbaarheid een van de hoofd referentiekaders om te onderzoeken. Want voor vele bedrijfskritische applicaties, is betrouwbaarheid inderdaad het meest belangrijkste aandachtspunt. Microsoft Access is, voor verscheidene redenen, niet bedoeld als een uiterst betrouwbare applicatie.
Database beschadiging
Wanneer Microsoft Access/Jet databases tegen een fout aanlopen of er is een verbindingsprobleem, raken ze beschadigd. Een beschadigde database vergrendeld normaliter alle gebruikers van de database. Dit leidt doorgaans tot het verlies van gegevens en de verstoring van de activiteiten.
Microsoft Access/Jet databases zijn vatbaar voor beschadigingen voor een aantal redenen. Omdat Access/Jet gebruik maken van het fileshare model, houden alle gelijktijdige gebruikers actieve verbinding met de data. Als iemand van die gebruikers onverwacht de verbinding kwijtraakt, vooral bij een data update proces, kan een database beschadigd raken. Dit kan gebeuren als het netwerk van de gebruiker is verbroken, driver versies niet up to date zijn, of als meerdere versies van de Jet DLL's worden gebruikt om hetzelfde database bestand te lezen.
Microsoft Access bevat een reparatie/comprimeer tool, maar databeschadiging wordt in het algemeen niet door dit tool gerepareerd. U zou de database naar derden kunnen sturen die een reparatie service ondersteunen, maar dit vereist dat de aangetaste database naar een andere locatie verzonden moet worden, u moet ervoor betalen en dan is het nog wachten wanneer het bestand terug komt. In het meest gunstigste geval zal ongeveer 90% van de laatste wijzigingen in tact zijn; de overige 10% is voor goed verloren.
Backup en onderhoudsproblemen
Omdat Access gebruik maakt van het fileshare model, is de gehele database vergrendeld op bestandsniveau zodra de eerste gebruiker toegang heeft gezocht. Dit betekent dat er geen betrouwbare mechanismen zijn voor het uitvoeren van backups van het database bestand, tenzij alle gebruikers de verbinding verbroken hebben.
In een multi-user omgeving is het vaak moeilijk een proces te coördineren om er zeker van te zijn dat alle gebruikers van de Access applicatie zijn uitgelogd, voordat het maken van backup gestart wordt. Er zijn typische scenario's waarin gebruikers betrokken zijn die hun computers aan laten staan wanneer zij het kantoor verlaten. Dit laat de database open en backup software wordt niet in staat gesteld een betrouwbare kopie van het database bestand te maken. Vaak wordt dit pas geconstateerd nadat een backup is mislukt en moet de systeembeheerder het probleem opsporen, hopelijk voordat de volgende backup wordt uitgevoerd. Bovendien is Access niet zelfherstellend. Het haalt niet als vanzelf verloren databaseruimte terug, of optimaliseert query's en indexen. Dit onderhoud kan worden uitgevoerd door een reparatie/comprimeer tool, maar dit vereist eveneens dat alle gebruikers zijn uitgelogd uit de database.
Omdat vele Access databases lokaal worden opgeslagen op computers gebruikers, worden ze vaak niet meegenomen in een gecentraliseerd backup of onderhoudsplan.
Verschillende versies van Access en de Jet Engine
Microsoft Access heeft een sterke afhankelijkheid van specifieke versies van de Jet Engine en andere gerelateerde Data Access Components. Als bijvoorbeeld nieuwe versies van Microsoft Data Access Components zoals DAO en ADO zijn geïnstalleerd, kunnen die ervoor zorgen dat bestaande Access applicaties niet meer werken. Dit is vooral waar voor de multi-user situaties. Dit gebrek aan neerwaartse compatibiliteit tussen hun driver versies, ontmoedigd de meeste organisaties te upgraden naar nieuwere versies van Office, omdat een nieuwe versie van Access er de oorzaak van zou kunnen zijn dat bestaande Access applicaties ermee ophouden.
Beveiliging
Microsoft Access biedt drie verschillende beveiligingsmechanismen.
- Database wachtwoorden. U kunt een wachtwoord aan een database toekennen. Alleen de gebruikers die het wachtwoord kennen, kunnen de database openen.
- Jet Werkgroep Beveiliging. Gebruikers-, groeps- en object-rechten kunnen worden toegekend en gedeeld met meerdere werkgroepen.
- Bestand encryptie. De inhoud van de database kan op bestandsniveau worden gecodeerd.
Helaas zijn deze mechanismen noch robuust, noch betrouwbaar. Database wachtwoorden gebruiken een erg eenvoudig encrypt mechanisme. In principe is het verwijderen van een Access database wachtwoord een simpel iets, gezien gratis en commerciële wachtwoord 'verwijderaars' gemakkelijk verkrijgbaar via het Internet. Hoewel Access gebruikers zich geen zorgen dienen te maken over zulke lage praktijken, zouden IT specialisten dat zeker wel moeten doen.
En hoewel de Jet Werkgroep Beveiliging een stuk robuuster is, laat het nog steeds de inhoud van de gehele MDB database open voor het bestandssystem. Omdat alle tabelgegevens en code zijn opgeslagen in het zicht, is het een koud kunstje om een MDB-bestand te openen in een string-compatibele editor en de code, wachtwoorden en tabelgegevens te bekijken.
Omdat Access voor alle gebruikers volledige leesrechten vereist tot het huidige database bestand, kan iedereen die een gedeelde netwerkschijf kan zien, kan weglopen met de database op een disk of USB-stick, of per e-mail naar buiten uw organisatie verzenden.
Opschaal scenario's
Belangrijk is te weten dat er meerdere mogelijkheden zijn voor het opschalen. Een kort overzicht van de verschillende scenario's.
| Scenario | Omschrijving |
|---|---|
| 1. Reeds goed geschaald. | Veel Access databases hoeven niet te worden opgeschaald. |
| 2. Alleen data opschalen. | Laat applicatie ontwerp en logica in Access, en verhuis de data naar SQL Server. |
| 3. Data en applicatie opschalen, gebruik maken van Access. | Herschrijf de applicatie in Access door gebruik te maken van een Access Data Project, verwijder de volledige behoefte aan de Jet Engine, en verhuis de data naar SQL Server. |
Scenario 1: Reeds goed geschaald
Klik hier om de afbeelding nogmaals te bekijken.Als u uw Access databases inventariseert, komt u misschien wel aan een lijst met tientallen, zo niet honderden databases verspreid over computers en netwerkschijven. Dit zijn meestal eenvoudige databases die gebouwd zijn door personeelsleden.
Met databases waarvan de aantallen in de honderden lopen, zal slechts een klein deel in aanmerking komen voor schaalvergroting. Dit vanwege de kosten en de verstoring van bedrijfsactiviteiten die dat met zich meebrengt.
Dus de eerste regel is dat de meeste databases niet moeten worden opgeschaald. De kosten zijn onbetaalbaar. Zelfs al zou u de middelen zelf in huis hebben om deze databases te converteren, dan nog zou dit geen echte aanwinst zijn. Eenvoudige lijsten en rapporten die door een enkele persoon gebruikt worden, vallen niet binnen het domein van kritische bedrijfsapplicaties. Deze toepassingen zijn eerder bestemd waarvoor Access is ontworpen en functioneren prima binnen de mogelijkheden die een personeelslid er zelf aan heeft toegevoegd.
Verder zijn databases die 6 tot 12 maanden niet meer gebruikt zijn, eveneens geen geschikte kandidaten voor opschaling. Deze bestanden zijn voor uw organisatie niet meer van belang.
Het belangrijkste voordeel binnen dit scenario is, dat u helemaal niets hoeft te doen, geen kosten en geen enkele bedrijfsverstoring heeft. Het nadeel is, dat Access/Jet gebaseerde applicaties niet kunnen schalen en niet de betrouwbaarheid en niet de beveiliging van SQL Server hebben. Maar dat is geen probleem voor de meeste databases binnen uw organisatie.
| Voordelen | Nadelen |
|---|---|
| Kosten: er is geen extra software nodig omdat Jet in Access is inbegrepen. | Beperkte schaalbaarheid. |
| Gemakkelijk in gebruik, geen SQL Server kennis vereist. | Beperkte beveiliging. |
| Laagste ontwikkelingkosten. | Beperkt aantal gelijktijdige gebruikers. |
| Beperkte betrouwbaarheid. | |
| Jet databases zijn geneigd te falen wanneer nieuwe versies van Office, Access, Jet of Data Access Componenten (zoals DAO en ADO) worden geïnstalleerd. |
Scenario 2: Alleen data opschalen
Klik hier om de afbeelding nogmaals te bekijken.Omdat Access de mogelijkheid biedt aan de SQL Server gekoppeld te worden voor de tabelgegevens, is migratie van uitsluitend de data, het beste balans tussen kosten en voordelen. In dit scenario wordt alleen de data in de tabellen naar SQL Server verhuisd en blijven de formulieren, de rapporten, de query's, de macro's en applicatie logica in de bestaande Access database.
Het belangrijkste voordeel binnen dit scenario is, dat het de minste impact heeft op de bestaande applicatie logica. Wellicht hoeven slechts een paar onderdelen van de applicatie te worden aangepast. Met een relatief kleine investering kunt u gebruik maken van de betrouwbaarheid en de onderhoudsvoordelen van SQL Server, en kunt u uw Access investering behouden.
Het grootste nadeel van dit scenario is, dat alle toegang tot SQL Server geschied door de Jet Engine. Dat is omdat de Jet Engine elke query en data verwerkingsproces moet vertalen van zijn gebruikelijke formaat naar SQL compatibele commando's. Deze vertaling benadeelt de prestaties, en maakt gebruik van extra SQL verbindingen die kunnen leiden tot extra SQL-licentie aankopen.
Scenario 2 is het beste voor Access applicaties met een klein aantal gebruikers en kleine databases van kleine omvang.
| Voordelen | Nadelen |
|---|---|
| Lage kosten voor het opschalen. | Het gebruik van Jet als een laag bovenop SQL Server kan de prestaties vertragen. |
| De data is opgeslagen in SQL Server hetgeen voor goede beveiliging, schaalbaarheid en betrouwbaarheid zorgt. | Kopieën van de gegevenstabellen (BackEnd) vereisen een synchronisatie. |
| Lokale Access bestanden bieden een meer beperkte beveiliging, schaalbaarheid en betrouwbaarheid. | |
| Omdat Jet nog steeds wordt gebruikt zijn lokale Access bestanden geneigd te falen wanneer nieuwe versies van Office, Access, Jet of Data Access Componenten (zoals DAO en ADO) worden geïnstalleerd. |
Scenario 3: Data en applicatie opschalen, gebruik maken van Access
Klik hier om de afbeelding nogmaals te bekijken.Als u de opschaling van een Access applicatie overweegt en de prestaties en schaalbaarheid zijn net zo belangrijk als de andere voordelen (betrouwbaarheid, beveiliging, onderhoud, etc.), dan kunt u overwegen om niet alleen de data naar SQL Server te verhuizen, maar om de gehele Access applicatie te herschrijven zodat de Jet Engine kan worden verwijderd.
Dit kan door gebruik te maken van een Access Data Project indeling dat beschikbaar is in Access 2000 en hoger. Access Data Projecten staan hetzelfde gebruik toe als formulieren, rapporten, macro's, code en intuïtieve ontwerptools die beschikbaar zijn in standaard Access databases. het grote verschil is, dat ze direct verbonden zijn met SQL Server om data te benaderen.
Er zijn twee situaties waarin u dit scenario zou moeten overwegen:
- Een bestaande Access applicatie gebruikt alleen de Jet Engine en moet worden opgeschaald naar SQL Server op een manier die optimale prestaties en schaalbaarheid biedt.
- Een bestaande Access applicatie is reeds verbonden met SQL Server via de Jet Engine en is toe aan betere prestaties en minder SQL Server verbindingen.
Het belangrijkste voordeel van dit scenario is, dat het resulteert in een Access applicatie die de beste prestaties en schaalbaarheid levert, bovenop alle andere positieve eigenschappen van SQL Server.
Het grootste nadeel van deze aanpak is, dat dit meer ontwikkelingstijd en meer expertise vergt omdat Access objecten zoals formulieren, rapporten, query's en code herschreven moeten worden om direct met SQL Server te kunnen werken.
| Voordelen | Nadelen |
|---|---|
| Profiteer van alle voordelen van SQL Server, inclusief de prestaties en de schaalbaarheid. | De kosten van het opnieuw ontwerpen van de applicatie logica en het opnieuw testen. Dit wordt natuurlijk teniet gedaan door de gewonnen verbeteringen. |
| De data is opgeslagen in SQL Server hetgeen uitstekende beveiliging en betrouwbaarheid biedt. |
Verschillende omstandigheden voor de migratie
Controle en aanpassing
Tot slot zijn er nog verschillende omstandigheden waarin applicaties verkeren voordat deze opgeschaald worden. Zelfs in scenario 2, waar waarschijnlijk weinig hoeft te worden aangepast, moeten bijvoorbeeld de gegevenstypen van alle tabelvelden worden gecontroleerd, want dit gegeven is voor VBA niet hetzelfde voor SQL Server. En in principe moet elke Access tabel een unieke sleutel hebben terwijl een SQL Server tabel er een moet hebben. Om maar een paar voorbeelden te noemen. Voor scenario 3 geldt, zoals vermeld, dat de aanpassing van programmacode nog veel intensiever is.
Het mag duidelijk zijn dat de Upsize wizard die Access 2000 of hoger bevat, zeker niet al het nodige werk kan doen als u wilt dat uw applicatie perfect zal functioneren.
Een Access applicatie migreren die u zelf heeft gemaakt?
De meeste Access applicaties worden gemaakt door handige werknemers die toch de expertise missen om een professionele applicatie te bouwen. Vaak worden er stukjes aan de database 'aangeknoopt' wanneer die behoefte zich voordoet. Fouten, onvolkomenheden en verkeerde logica blijven achter waardoor de applicatie niet meer betrouwbaar is, niet goed te onderhouden en uit te breiden is, niet gebruiksvriendelijk werkt, etc. etc. En laat u niet misleiden dat wanneer u de applicatie door een 'specialistisch bedrijf' heeft laten ontwikkelen, deze mankementen dan niet aanwezig zullen zijn.
Om de migratie succesvol te laten verlopen, is het dus noodzakelijk dat de applicatie aan een aantal voorwaarden voldoet als u uw investering 100% zeker wilt stellen. Office Programs zal de applicatie dus altijd vooraf analyseren en u een eerlijk advies uitbrengen. Tot in hoeverre u de aanpassingen wilt laten doorvoeren of een geheel nieuwe applicatie wilt laten bouwen, is aan u. Het prijsverschil wordt helemaal bepaald door de toestand waarin de huidige applicatie verkeerd. Zie de pagina Updaten of een nieuwe applicatie ontwikkelen? voor een uitgebreider advies.
Testen
Nadat alles intensief is gecontroleerd en aangepast, zal er uitvoerig worden getest. Enkele van uw medewerkers zullen met de applicatie gaan proefdraaien en kunnen feedback geven. Nadat alles correct en naar tevredenheid werkt, kan de applicatie definitief in gebruik worden genomen.
Zie ook...
