Az adatbázis-adminisztrátor feladatainak nagy része a változások kezeléséből áll. Az üzleti változások általában szükségessé teszik az alkalmazáskód vagy az adatbázis-struktúra változását. A legegyszerűbb üzleti változás is hatással van az adatbázisra, pl. az üzlet nő és ezért több felhasználó fogja használni az adatbázist, vagy újabb típusú adatok tárolására van igény vagy egyszerűen csak a tranzakciók mennyiség nő. Az üzleti változások mellett a technológiai változások is hatással vannak a rendszerünkre, pontosabban az adatbázis-kezelő szoftverre. Ilyen technológiai változások lehetnek az adatbázis-kezelő rendszer frissítései vagy a hardver elemek cseréje. Mind az üzleti, mind a technológiai változások az adatbázis-adminisztrátor feladatait szaporítják.
Ha az adatbázis-kezelő rendszernek új verziója vagy új kiadása kerül a piacra, akkor az adatbázis-adminisztrátornak elő kell készülnie az új verzióra vagy új kiadásra történő migrálásra. A feladat összetettsége nagyban függ az új verzió által támogatott új tulajdonságoktól és funkcióktól, illetve attól is, hogy az új verzióban mi hiányzik, ami még a régiben megvolt. Ha az adatbázis vagy a programok a régi verzióban olyan funkciót használnak, amelyet az új verzió nem tartalmaz, akkor az adatbázist is és a programokat is változtatni kell. Előfordulhat az is, hogy megvan az új verzióban ugyanaz a funkció, de átnevezésre került. Az adatbázis-adminisztrátornak az új adatbázis-kezelő rendszer tulajdonságok megfelelő használatához megfelelő vezérelveket és módszereket kell létrehozni.
Az adatbázis-kezelő rendszer igénye miatt szükség lehet hardver frissítésre vagy konfiguráció változásra. Az adatbázis-adminisztrátortól elvárják, hogy a rendszerprogramozóval vagy rendszer-adminisztrátorral együtt konfigurálja és karbantartsa a hardvert. Az adatbázis-kezelő rendszer igényelhet speciális hardverelemeket, hogy a különböző tulajdonságait ki tudja használni. Az adatbázis-adminisztrátor a rendszerprogramozóval együtt találja ki, hogy milyen hardverkonfiguráció szükséges.
A hardver változhat valamilyen adatbázistól független okból is, ami lehet például lemez- vagy memóriaváltozás. Ebben az esetben is előfordulhat, hogy az adatbázis-kezelő rendszernek is változnia kell, ami jelentheti az adatbázis-kezelő rendszer konfigurációjának a változását vagy adatbázis-struktúra változást.
Ha az adatbázis változik fontos, hogy az adatbázisterv is változzon. Ez azt jelenti, hogy a koncepcionális és a logikai adatmodellt a fizikai adatbázissal szinkronban kell tartanunk. Ezt különbözőképp lehet végrehajtani.
Az adatadminisztrációban jártas cégek azt választanák, hogy először a koncepcionális és logikai szinten végezzük el a változásokat és aztán migráljuk azt a fizikai adatbázisba. Általában egy ilyen megközelítéshez szükség van egy adatmodellező eszközre, amely elkülönítetten kezeli a logikai és fizikai modellt. Ez az adatmodellező eszköz a legtöbb esetben megkönnyíti a különböző szintek változásainak megadását, illetve képes szinkronizálni a különböző modellek között mindkét irányban: a logikaitól a fizikaiig és vissza.
Robusztus adatmodellező eszköz hiányában a modellek szinkronizációja általában kézzel történik. Ha a fizikai adatbázis módosul, az adatbázis-adminisztrátornak kézzel kell a logikai adatmodellt módosítani (és esetleg a koncepcionális adatmodellt is). Az ilyen munka hosszadalmas, nagy pontosságot igényel, ezért unalmas lehet. Minden kézi változtatás hibalehetőséget tartalmaz. A logikai és a fizikai modellnek szinkronizáltnak kell lennie. Ha mégsem az, az adatmodell nem lesz használható az adatbázis-fejlesztéshez.
Az alkalmazásváltozásoknak és az adatbázis-változásoknak egymással szinkronban kell lenniük. Ezt általában könnyebb mondani, mint megtenni. Ha a fizikai adatstruktúrában történik a változás, akkor azt az alkalmazásváltozások a legtöbb esetben követniük kell. Például ha egy adatbázistáblához egy oszlopot adunk hozzá, akkor ez megköveteli az alkalmazásszoftver változását úgy, hogy az módosítani, illetve lekérdezni tudja az adatot az új oszlopból.
Ha az adatbázis-változás a termelési környezetbe kerül, az alkalmazásváltozásnak is át kell kerülnie. Ha nem kerül át, az adatbázis-változás hatástalan lesz, rosszabb esetben az alkalmazás működésképtelenné válik. Az adatbázis-adminisztrátor megteheti, hogy először az adatbázis-változást az alkalmazásváltozás nélkül vezeti át a termelési rendszerbe, hogy biztosítsa, hogy az adatbázis-struktúra megfelelően legyen megadva. Miután az adatbázis a termelési környezetben módosult, az adatbázis-adminisztrátor megvizsgálja az adatbázis pontosságát, majd csak ezután kezdheti el az alkalmazás-változás migrálását.
Az adatbázis-változás és az alkalmazásváltozás között szoros kapcsolat van. Ha az alkalmazásváltozást visszavonják, az adatbázis-változást is vissza kell vonni, és fordítva. Ha hibázunk a változások szinkronizálásában, az alkalmazáshibát vagy hatástalanságot eredményezhet. Fontos, hogy az adatbázis-adminisztrátor megértse a kapcsolatot és figyelje a változás folyamatát, így tudja biztosítani, hogy az adatbázis- és alkalmazásváltozások valóban bekövetkeznek egymás után.
A legtöbb adatbázis idővel változik. Nagyon ritka, hogy egy egyszer megvalósított adatbázis statikus marad. Néhány változás egyszerűen megvalósítható, mások nagyon összetettek, sok hibalehetőséget rejtenek és sok időre van szükség hozzájuk. A legbonyolultabb és a legtöbb időt felemésztő változástípus az adatbázis-adminisztrátor számára a fizikai adatstruktúra változása, amelyet ugyancsak tervezni, elemezni kell, majd csak ezután következhet a változás megvalósítása.