Delphi Yrityssovellukset: Miksi monet järjestelmät toimivat vakaasti – ja miten pidät ne tulevaisuuden kestävinä

Monissa yrityksissä Delphi yrityssovellukset ovat toimineet luotettavasti vuosia: tuotantoläheiset kirjaukset, disponointi, varasto, lähetys, huolto, laadunvarmistus tai hallinnolliset ydinprosessit. Tällaiset järjestelmät eivät usein ole „kauniita“, mutta ne ovat usein erittäin arvokkaita – koska ne mallintavat prosesseja, joita ei saa puristettua standardiohjelmistoihin. Juuri siksi Delphi on käytännössä edelleen merkityksellinen: ei trendinä, vaan vakaana perustana yksilölliselle yritysohjelmistolle, joka on syntynyt aikapaineessa ja kasvanut vuosien aikana.

IT-johtajille ja ylläpidolle kysymys ei ole niinkään „Delphi: kyllä vai ei?“, vaan: miten pidän järjestelmän käytettävänä, turvallisena ja muokattavana, ilman että estän toimintaa Big-Bang-uudistuksella? Tämä kirjoitus luokittelee tyypilliset Delphi-ympäristöt ja esittää käytännönläheisiä modernisointipolkuja – keskittyen käyttöön, datoihin, rajapintoihin, ylläpidettävyyteen, tietoturvaan ja migrointiin. Ei frameworkien sisäpiiritystä, mutta konkreettisia päätöksiä, joilla on merkitystä arjessa.

Miksi Delphi jää yrityksiin – ja miksi se ei välttämättä ole huono asia

Monet Delphi-sovellukset rakennettiin aikana, jolloin työpöytäsovellus (VCL, eli perinteinen Windows-käyttöliittymä) oli nopein tapa digitalisoida prosesseja. Näistä syntyi järjestelmiä, joissa on korkea toimialalogiikan tiheys, tiukat tietokantassidonnaisuudet ja lukuisia „pieniä“ erityistapauksia, jotka yhdessä pitävät toiminnan pystyssä. Tämä selittää pitkäikäisyyden: liiketoimintalogiikka on testattu – ei unit-testeillä, vaan vuosien tuotantokäytöllä.

Riskit eivät yleensä johtu Delphi-kielestä sinänsä, vaan siihen liittyvistä reuna-alueista: vanhat tietokantayhteydet (esim. BDE, eli Borland Database Engine), 32-bittiriippuvuudet, vanhentunut salaus, epäselvät rajapinnat, observabilityn puute (monitorointi/lokit), huonosti määritellyt käyttöoikeusmallit tai päivitysstrategioiden puute. Kun nämä reuna-alueet modernisoidaan, Delphi-sovellus voi jatkaa erittäin luotettavana osana yrityksen digitaalisia ratkaisuja.

Tyypilliset lähtökohdat: Näin Delphi yrityssovellukset näyttävät käytännössä

Kuka tahansa, joka ottaa vastuulleen tai vakauttaa Delphi-ympäristön, kohtaa usein sekoitusmuotoja. Suunnittelun ja budjetoinnin kannalta on hyödyllistä nimetä lähtötilanne selkeästi:

• Monoliittinen työpöytäasiakas suoran tietokantayhteyden kanssa (usein historiallisesti kasvanut, osin „Fat Client“-logiikalla).
• Client-Server palveluilla: Windows- ja Linux-palvelut tai Linux-daemon hoitavat taustatehtäviä (tuonnit, viennit, tulostusajot, sähköposti, ajoitukset).
• Hybrid: työpöytä pysyy johtavana käyttöliittymänä, lisäksi REST-API portaalille tai kolmansien osapuolien liitännöille (REST = HTTP-pohjainen rajapinta, joka toimittaa tiedot yleensä JSON-muodossa).
• Useita tietolähteitä: SQL Server/PostgreSQL plus perintöjärjestelmät (Firebird, Paradox-tiedostot, DBF, Access).
• Terminalserver/RDS tai Virtual Desktop Infrastructure (VDI) keskitettyyn käyttöön, osin periferialiitännöillä (skannerit, vaa’at, etikettitulostus).

Jokainen näistä vaihtoehdoista voi toimia – mutta modernisoinnin painopisteet eroavat. Työpöytämonoliitti tarvitsee usein ensin eriyttämistä ja selkeämpiä rajapintoja. Palveluympäristö vaatii selkeää operointihallintaa, versiointia ja monitorointia. Sekamuodoissa tieto- ja rajapintastrategiasta tulee keskeinen vipu.

Modernisointi ilman Big Bangia: päätöslogiikka IT:lle ja päätöksentekijöille

Keskeisin päätös on: Mitä pitää vakauttaa nopeasti, ja mitä voidaan modernisoida vaiheittain? Täydellä uudisrakennuksella on suuria riskejä: rinnakkainen toiminnallinen konseptityö, kaksinkertainen ylläpito, migraatiokaistat ja usein aliarvioidut „sivutoiminnot“ (Sonderdrucke, Korrekturläufe, Notfallprozesse). Samalla ei saa sivuuttaa todellisia estoja (esim. BDE, ei-patchattavat riippuvuudet, tietoturva, jota ei voi auditoida).

Käytännössä toimii kolmiosainen tiekartta:

• Vakauttaminen: build-prosessi, toistettavat julkaisut, selkeä lokitus, backup/restore-testit, nopeat hyödyt tietoturvassa.
• Eriyttäminen: selkeät kerrokset (esim. Layer-3-arkkitehtuuri: UI, business-logiikka, tietojen käyttö), rajapintojen määrittely, tietojen käyttökerroksen modernisointi.
• Laajentaminen: REST-APIt, portaalit, uudet clientit, uudet tietokannat, monialustaisuus, moniasiakastuki – siellä, missä se on toiminnallisesti ja taloudellisesti perusteltua.

Avain on, että jokainen vaihe tuottaa käyttökelpoisen tilan eikä vain „esivalmisteluja“. Näin prosessikyky säilyy ja muutokset pysyvät hallittavina.

Delphi modernisointi: missä suurimmat riskit todellisuudessa ovat

Termi „modernisointi“ käytetään usein liian yleisesti. Operoinnin kannalta tyypillisesti viisi riskialuetta ovat ratkaisevia:

1) Tietojen käyttö ja ajurimaisema (BDE, ODBC, vanhentuneet clientit)

BDE-korvaus on klassikko: niin kauan kuin Borland Database Engine on tuotantokäytössä, syntyy konflikteja nykyisten Windows-versioiden, ajurien, käyttöoikeuksien ja tietoturvan peruslinjausten kanssa. Lisäksi operointi muuttuu hauraaksi, koska komponentteja ei enää ylläpidetä. Tässä on BDE-korvaus natiiviliitännällä usein pragmaattinen modernisointiaskelma: moderni tietojen käyttökerros Delphi-ympäristössä, joka liittää eri tietokannat siististi ja tekee ajuri-/poolausasioista helpommin hallittavia.

Tärkeää IT:lle: BDE-korvaus ei ole pelkkää „ajurin vaihtoa“. Tyypillisiä jatkotöitä ovat SQL-dialektin mukautukset, transaktiorajojen määrittely (transaktio = samaan kokonaisuuteen kuuluvat tietokantamuutokset, jotka joko otetaan kokonaan tai eivät lainkaan), virheenkäsittely, merkistö/Unicode ja suorituskyvyn profilointi.

2) 32‑bit-riippuvuudet ja siirtymä 64‑bittiin

Siirtymä 64‑bittiin ei yleensä epäonnistu Delphi:n itsensä vuoksi, vaan ulkoisten komponenttien takia: tulostinohjain-wrapperit, vanhat COM/ActiveX-kirjastot, erityiset laite-SDK:t tai vanhentuneet tietokantaclientit. Suunnittelussa on pakollinen riippuvuusinventaario: Mitä DLL:iä ladataan? Mitkä komponentit eivät ole 64‑bittisiä? Onko korvaajaa tai voiko toiminnon siirtää erilliseen prosessiin (esim. palveluksi)?

Puhdas lähestymistapa on ottaa 64‑bittisyys käyttöön ensin siellä, missä siitä on operatiivista hyötyä (muistivaatimus, suuret tietomäärät, nykyaikaiset alusta‑vaatimukset) – ja kapseloida 32‑bittinen toiminnallisuus reunafunktioita varten väliaikaisesti sen sijaan, että estettäisiin koko asiakasohjelma.

3) Unicode‑migraatio ja datan eheys

Unicode tarkoittaa: tekstit eivät enää tallennu paikallisiin koodisivuihin, vaan yhtenäiseen merkistöön (tyypillisesti UTF‑16/UTF‑8 riippuen tasosta). Kasvaneissa Delphi‑sovelluksissa tämä koskee vanhoja tietokenttiä, vientiformaatteja, tulostuspohjia ja rajapintoja. Ongelmia ilmenee usein vasta käytännössä: erikoismerkit nimissä, kansainväliset osoitteet, artikkelitekstit, sähköpostisisällöt.

Yrityksille on ratkaisevaa testata päädystä päähän: tietokannan kollaatio, tuonti/vienti (CSV, XML, JSON), EDI‑formaatit, PDF:n generointi, SMTP/IMAP, ja myös näyttö käyttöliittymässä. Unicode‑migraatio on toteutettavissa, mutta se vaatii testejä todellisilla datoilla ja selkeät hyväksymiskriteerit.

4) Rajapinnat ja integraatiot (REST, ERP, DMS, Identity)

Monet Delphi‑järjestelmät ovat „saarekkeita“, koska suora tietokantakäyttö oli historiallisesti nopein tapa. Nykyään tarvitaan siistejä integraatioita: ERP, DMS, CRM, portaalit, koneiden liitäntä. Tällöin on osoittautunut hyväksi ulkoistaa integraatiologiikka REST‑palveluihin tai taustapalveluihin. Delphi REST‑API ja REST‑Server ei ole tarkoitus sinänsä, vaan käyttökomponentti: versioidut päätepisteet, selkeä todentaminen, kontrolloitu lokitus ja rajattu tietojakelu.

Lisäksi Identity tulee merkitykselliseksi: SAML 2.0 (Single Sign‑on yrityksen identiteetin ja sovelluksen välillä) tai OAuth2/OpenID Connect, ympäristöstä riippuen. Päätös koskee paitsi sovellusta myös käyttöä, auditointia ja offboarding‑prosesseja.

5) Käyttö: Updates, Monitoring, Recovery

Sovellus on yrityksessä yhtä hyvä kuin sen käyttö. Tyypillisiä heikkouksia: manuaaliset asennukset, puuttuva rollback‑strategia, vähäinen telemetria ja epäselvät vastuujako häiriötilanteissa. Modernisointi ei tässä tarkoita „Cloudia“, vaan: toistettavat käyttöönotot, jäljitettävät konfiguraatiot ja mitattavissa oleva järjestelmän terveydentila.

Arkkitehtuuri, joka auttaa arjessa: Layer-3, selkeät rajat, vähemmän sivuvaikutuksia

Kun Delphi‑projektit kasvavat vuosien aikana, käyttöliittymälogiikka sekoittuu usein liiketoimintasääntöihin ja tietokantakäyttöön. Se tekee muutoksista riskialttiita: uusi kenttä dialogissa aiheuttaa yhtäkkiä sivuvaikutuksia tuonnissa tai raporteissa. Layer-3‑arkkitehtuuri (presentaatio, liiketoimintalogiikka, tietokantakäyttö) on tässä vähemmän teoriaa ja enemmän käytännöllinen keino tehdä muutoksista laskettavissa olevia.

Tärkeää on riippuvuuksien suunta: käyttöliittymä saa käyttää liiketoimintafunktioita, mutta liiketoiminnan ei pitäisi tietää, miten painikkeet on nimetty. Tietokantakäyttö toimittaa olioita/tietoja, mutta ei päätä toiminnallisista säännöistä. Tämä helpottaa:

• kohdennettuja testejä liiketoimintasäännöille ilman, että käyttöliittymää tarvitsee käynnistää,
• askel‑askelelta korvaamista tietokantakäytössä (esim. BDE → BDE-Ablosung mit nativer Anbindung),
• useiden käyttöliittymien rinnakkaisajoa (työpöytä sekä portaali),
• vakaampia julkaisuja, koska sivuvaikutukset vähenevät.

Päättäjille tämä on kustannusargumentti: ei siksi, että arkkitehtuuri olisi „kaunis“, vaan koska se tekee ylläpidosta ennustettavampaa.

Tietokantojen modernisointi: FireDAC, PostgreSQL, SQL Server – ja mitä se merkitsee tuotantokäytölle

Tietokantaratkaisujen valinnat Delphi-yrityssovelluksissa ovat usein historiallisia. Käytössä ratkaisevat erityisesti: varmuuskopiointi/palautus, valvonta, HA/Failover, tietoturvapaikkaukset ja käyttöoikeuksien hallinta. Tietokanta‑pääsyn mallin tulee tukea näitä vaatimuksia.

FireDAC standardointikerroksena

FireDAC voi toimia teknisenä standardointikerroksena, koska yhteydenhallinta, parametrien sitominen, transaktiot ja ajurivalinnat tulevat yhdenmukaisemmiksi. Käytön kannalta tärkeää on: connection pooling (yhteyksien uudelleenkäyttö), timeoutit ja selkeä virheluokitus (esim. ‚Deadlock‘, ‚Timeout‘, ‚Unique Constraint‘).

PostgreSQL tuotantokäytössä yhdessä Delphi: mahdollisuudet ja sudenkuopat

PostgreSQL valitaan usein, kun avoimet standardit, hyvä SQL‑toiminnallisuus ja hyvät operointimahdollisuudet ovat tärkeitä. Tyypillisiä huomioita migraatiossa:

• Tietotyypit: päivämäärä/aika, Boolean, UUID, JSONB – käytä niitä oikein tietomallissa sen sijaan, että tallennettaisiin kaikki tekstinä.
• Transaktioiden eristys: yhdenmukaisuus vs. rinnakkaisuus; merkityksellinen kirjanpitologiikassa ja eräajoissa.
• Indeksistrategia: suorituskyky syntyy harvoin „enemmän CPU:lla“, vaan sopivilla indekseillä ja puhtailla kyselyillä.

Ylläpitäjille on tärkeää, että sovellus ei vaadi ‚Superuser’‑oikeuksia, vaan toimii vähimmillä rooleilla. Tämä on keskeinen kohta auditoinneissa ja tietoturvatarkastuksissa.

SQL Server -liitännän modernisointi

Monissa ympäristöissä SQL Server on vakiovalinta. Tässä kyse ei välttämättä ole migraatiosta vaan oikeasta käytöstä: parametrisoidut kyselyt (SQL‑injektiota vastaan), järkevä eristystaso, Stored Proceduresin käyttö siellä, missä governance sitä edellyttää, sekä selkeä ero sovellus‑ ja ylläpitäjäkirjautumisten välillä. Käytännössä kannattaa myös tarkistaa kollaatioasetukset (lajittelu/merkkivertailu), koska ne vaikuttavat Unicode‑aiheisiin ja vertailuihin (esim. iso/pienikirjainten käsittely).

REST-API:n jälkiasennus: integraatiot mahdolliseksi ilman tietokannan ‚avaamista‘

Kun portaaleja, mobiiliprosesseja tai kolmansia osapuolia halutaan kytkeä, suora tietokantayhteys on yleensä huonoin vaihtoehto: vaikea versioida, riski datan eheyteen, vaikea auditoida. REST-API luo hallitun integraatiokerroksen. Se määrittelee, mitä tietoja milläkin formaatilla ja millä säännöillä tarjotaan.

Käytön ja turvallisuuden kannalta neljä asiaa ovat ratkaisevia:

• Todennus: token‑pohjainen, mieluiten kytkettynä keskitettyihin identiteetteihin (esim. SAML 2.0/OIDC etuvartin kautta, arkkitehtuurista riippuen).
• Autorisointi: oikeuksien tarkastus liiketoimintaobjekteissa, ei pelkästään ‚käyttäjä saa käyttää endpointia‘.
• Versiointi: endpoint‑ tai payload‑versiot, jotta portaali ja backend voidaan deployata itsenäisesti.
• Rate limits ja lokitus: suoja väärinkäytöltä ja luotettava diagnoosi häiriötilanteissa.

Monissa yritysverkoissa tällaiset palvelut ajetaan Reverse Proxyn takana (esim. nginx). Tällöin Forwarded‑otsikoinnin käsittely pitää olla kunnossa (todellinen client‑IP, HTTPS‑tunnistus, oikeat URL‑baset), muuten lokit, uudelleenohjaukset ja turvallisuussäännöt eivät pidä paikkaansa. Tämä ei ole pikkuasia, vaan merkityksellinen häiriöanalyysin ja vaatimustenmukaisuuden kannalta.

Windows-Service und Linux-Services: taustaprosessien asianmukainen operointi

Delphi-järjestelmää käytetään yrityksissä paitsi työpöytäkliensseihin myös palveluihin: tiedon tuontiin, ajastimiin, sähköpostin lähetykseen, PDF:n luontiin, rajapintojen työprosesseihin. Käytössä ratkaisee, että palvelu ei vain ‚jotenkin pyöri‘, vaan se voidaan käynnistää, pysäyttää ja valvoa hallitusti.

Tarkistuslista palveluvalmiille Delphi-komponenteille

• Konfiguraatio ulkoisesti: ei ‚kovakoodattuja‘ polkuja/hosteja binaaritiedostossa; konfiguraatio tiedostona/ympäristömuuttujina, selkeällä dokumentaatiolla.
• Graceful Shutdown: käynnissä olevat tehtävät päättää tai peruuttaa siististi, jotta ei synny puolikkaita tietueita.
• Idempotenssi: saman tehtävän toistaminen ei saa aiheuttaa kaksoiskirjauksia (idempotenssi = sama kutsu, sama tulos).
• Lokitus korrelaatiotunnisteilla: jokaiselle tehtävälle/transaktiolle ID, jotta lokit voidaan yhdistää useiden komponenttien yli.
• Monitorointi: health-endpointit tai vähintään tarkistettavat metriikat (esim. ‚viimeinen ajo‘, ‚virheprosentti‘, ‚jonon pituus‘).

Bei Linux-Services (z. B. als Daemon unter systemd) kommen Paketierung, Rechtekonzept und Dateisystem-Layout hinzu. Entscheidend ist, dass die Service-Identität minimal berechtigt ist und Secrets (Passwörter, Tokens) nicht als Klartext im Deployment liegen. Je nach Umgebung kann ein Secret-Store oder zumindest ein abgesicherter Konfigurationspfad nötig sein.

Tietoturva ja vaatimustenmukaisuus: mitä Delphi-sovelluksissa tyypillisesti pitää päivittää

Monet olemassa olevat sovellukset ovat toiminnallisesti oikein, mutta tietoturvaa arvioitiin ’silloin‘ eri tavalla. Nykyvaatimukset ovat selkeämmät: päivitettävyys, jäljitettävyys, salaus, pääsynhallinta. Tyypillisiä toimenpiteitä, joilla on korkea hyöty/riski-suhde:

• Siirtojen salaus: TLS palveluille ja API-yhteydille, ei salaamattomia HTTP-yhteyksiä sisäverkossa ‚tottumuksesta‘.
• Salasanojen ja salaisuuksien käsittely: ei salasanoja INI-tiedostoissa ilman suojausta; mahdollisuuksien mukaan keskitetty identiteetin hallinta ja tokenit.
• Audit-lokitus: kuka teki minkäkin kriittisen toimenpiteen (perustiedot, hyväksynnät, vienti), aikaleiman ja identiteetin kanssa.
• Käyttöoikeusmalli: mallinna roolit ja oikeudet toiminnallisesti; erottele ylläpitäjätoiminnot; tarkista monivuokralaisuuden eristys.
• Kryptografia pragmattisesti ja oikein: ei itse kehitettyjä algoritmeja; vakiintuneet menetelmät kuten AES (symmetrinen) ja ajantasaiset hajautukset sekä eheydensuoja.

Tärkeää: tietoturva ei ole vain koodia. Se koskee myös käyttöä (palvelimien käyttöoikeudet, lokien säilytys, varmuuskopioiden salaus) ja prosesseja (häiriötilanteiden käsittely, säännölliset päivitykset, komponenttien elinkaaren päättäminen).

Migraation suunnittelu: kasvaneesta järjestelmästä roadmap-kykyiseksi alustaksi

Jos Delphi-sovellusta aiotaan jatkaa strategisesti, sille tarvitaan roadmap, joka yhdistää tekniset ja organisatoriset näkökohdat. Käytännöllinen lähestymistapa alkaa läpinäkyvyydellä:

1) Tekninen nykytilan kartoitus, joka kuvaa käytön ja riskit

• Komponenttiluettelo (Delphi-versiot, kolmannen osapuolen kirjastot, ajurit, palvelut, asennusohjelmat)
• Tietokannat ja tietovirrat (Import/Export, batch-tehtävät, raportointi)
• Rajapinnat (tiedosto, TCP/IP, REST, SOAP, sähköposti, ERP/DMS/CRM)

2) Määrittele tavoitetila, mutta älä ylikuormita

Tavoitetila on hyödyllinen, jos se helpottaa päätöksentekoa. Sen tulisi kuvata, miten jatkossa julkaisut syntyvät, miltä rajapinnat näyttävät, miten tietojen käyttö standardoidaan ja miten käyttöä valvotaan. Sen ei tarvitse tarkoittaa „kaiken uusimista“. Usein riittää tavoitetila, jossa on kolme–viisi ohjenuoraa: esim. FireDAC standardina, REST integraatioille, palvelut monitoringilla, Identity-liitännät, selkeät kerrokset.

3) Toteutus selkeästi rajattavissa olevissa paketeissa

Modernisointipaketit tulisi olla toiminnallisesti ja teknisesti eroteltavissa: „BDE pois ja tietojen käyttö standardoidaan“, „REST-API portaali-käyttötapauksille“, „64‑bit-asiakas plus yhteensopivuuskapseli“, „palvelutuotannon koventaminen“. Jokaisella paketilla tulee olla hyväksymiskriteerit: mitattavissa oleva vakaus, määritelty suorituskyky, dokumentoidut operointiprosessit.

C# ja Delphi yhdistäminen: Kun portaalit ja palvelut syntyvät työpöydän rinnalle

Monissa yrityksissä Delphi on vakiintunut ydinjärjestelmään, kun taas portaalit tai uudet integraatiopalvelut syntyvät ennemmin C#/.NET:llä. Tämä ei ole ristiriita, kunhan arkkitehtuuri erottaa selkeästi: Delphi voi jatkaa prosessiläheisen työpöytäjärjestelmän vakaata ylläpitoa, kun taas C# portaalit tai C# palvelut vastaavat moderneihin web-vaatimuksiin. Ratkaisevaa on järjestelmien yhteinen kieli: selkeät datakontraktit, yhdenmukaiset identiteetit, jäljitettävät rajapintaversiot ja selkeä monitorointi järjestelmärajojen yli.

IT-johtajille tämä on usein taloudellisin vaihtoehto: olemassa oleva arvonluonti pysyy käytössä, kun taas uudet kanavat voidaan avata ilman täydellistä migraatiota.

Mitä teidän tulisi valmistella sisäisesti: Dokumentaatio, käyttöopas, osaamisen siirto

Delphi-järjestelmiä kantaa usein vain muutama henkilö. Se on riski, joka on kohtuullisella vaivalla vähennettävissä. Erityisen tehokkaita ovat:

• Käyttöopas: palvelut, portit, konfigurointi, Cron/aikatauluttaja, tyypilliset häiriöt, palautustoimenpiteet.
• Release-muistiinpanot: mitä muuttuu, mitkä DB-migraatiot suoritetaan, miten palautus on mahdollista?
• Rajapintakatalogi: päätepisteet/formaatit, tiedostojen vaihto, yhteyshenkilöt, versiot.
• Tietomallin yleiskatsaus: keskeiset taulut/entiteetit, avaimet, moniyrityslogiikka, arkistointi.

Tämä ei ole byrokratiaa, vaan perusta ennakoitavalle tuotannolle, nopeammalle häiriöiden käsittelylle ja pienemmälle riippuvuudelle yksittäisiin henkilöihin.

Fazit: Delphi yrityssovellukset eivät ole ongelma – puuttuvat modernisointipolut ovat

Delphi-yrityssovellukset voivat vuosien ajan muodostaa luotettavan, taloudellisen ytimen prosessiläheisille ohjelmistoratkaisuille. Kritinen seikka ei useinkaan ole kieli, vaan vanhojen ajureiden, epäselvien rajapintojen, puutteellisen tuotannon koventamisen ja laiminlyötyjen turvallisuusmekanismien summa. Se, joka suunnittelee stabiloinnin, irrottamisen ja laajennuksen kontrolloiduksi roadmapiksi, välttää riskialttiin Big Bangin – ja saa silti REST-integraatiot, 64‑bit-tuen, puhtaat tietokäytöt ja tuotantoympäristön, joka vastaa nykyvaatimuksia.

Jos haluatte teknisesti luokitella Delphi-maisemanne ja laatia luotettavan modernisointipolun tietokäyttöön, rajapintoihin ja tuotantoon, ottakaa yhteyttä meihin:

Keskustele projektista tai modernisointihankkeesta Net-Base kanssa.