Køreplan for migration fra monolit til mikrotjenester: modernisering af virksomhedsapps

Michael Labutin

5. april 2025 12 minutter

Hvis du er her, er dit monolitiske system sandsynligvis ved at blive mere en byrde end et aktiv. Langsomme udgivelsescyklusser, hovedpine ved skalering og en stiv arkitektur gør det sværere at følge med. Jo større din app bliver, jo mere frustrerende bliver den. Ny teknologi integreres ikke gnidningsløst, smidigheden lider et knæk, og pålideligheden begynder at skride.

Microservices kan vende op og ned på tingene ved at gøre dit system modulært, fremskynde implementeringer og give dig mulighed for at skalere præcis det, du har brug for, når du har brug for det. Men her er hagen: Migrering handler ikke kun om at opdele kode. Hvis du ikke planlægger det rigtigt, kan du ende med mere kompleksitet, integrationsmareridt og uventede omkostninger.

I denne artikel gennemgår jeg en køreplan fra den virkelige verden for at gå fra monolit til mikrotjenester. Intet fnidder - bare praktiske trin, hårdt tjente erfaringer fra vores løsningsarkitekterog strategier, der rent faktisk virker. Lad os dykke ned i det.

Trin til at migrere fra monolitisk til mikrotjenestearkitektur

Trin 1: Planlægning af en migrering fra monolit til mikrotjenester

Jeg har set mange virksomheder, der tror, at mikrotjenester er den magiske løsning, men som ender med mere kompleksitet, ødelagte arbejdsgange og skyhøje omkostninger. Og hvis der er én ting, jeg har lært, så er det, at det er en hurtig vej til kaos at springe direkte ud i den tekniske side uden en solid plan.

Det er fristende at begynde at skille en monolit ad og oprette tjenester, men før vi overhovedet rører ved koden, arbejder vi sammen med kunderne om at kortlægge migreringens hvorfor, hvornår og hvordan. På den måde giver hvert skridt fremad faktisk værdi.

Sæt de rigtige mål: Hvorfor migrerer du?

Når kunder kommer til os for at skifte fra monolith til microservices, spørger jeg, hvad der driver deres beslutning om at flytte. Svarene varierer, men oftest hører jeg, at det er, fordi deres konkurrenter gør det. Og helt ærligt, det er ikke nogen god grund. At springe ud i mikrotjenester uden et klart mål fører som regel bare til mere hovedpine, ikke til egentlige fremskridt.

Så spørg dig selv, før du tager springet:

Hvad håber du at opnå?
Har du overvejet alternativer til at bruge mikrotjenester?
Hvordan vil du vide, om overgangen fungerer?

Hvis du ikke er 100% sikker - bare rolig. Vi hjælper dig med at definere de vigtigste målinger og forretningsresultater på forhånd, så hver teknisk beslutning flytter nålen.

Microservices: passer til alle? Ikke altid

Microservices giver modularitet, uafhængig skalering og hurtigere innovation. Men de er ikke en sølvkugle. Nogle virksomheder klarer sig fint med en monolit, især hvis deres app er enkel, stabil og ikke ændrer sig meget.

Forestil dig en lille medarbejderportal eller et lagersystem, som kun en håndfuld mennesker bruger. Hvis det fungerer fint og ikke har brug for konstante opdateringer, kan det at opdele det i mikrotjenester bare tilføje en masse kompleksitet uden nogen reel gevinst.

Det er derfor, vi ikke skubber på med microservices bare for at gøre det. I stedet ser vi på, hvad du specifikt har brug for, og om mikrotjenester vil give reelle fordele. Hvis det er tilfældet, er det fantastisk - så går vi i gang. Hvis ikke, finder vi en bedre vej frem.

Vurdering af monolitten: Vid, hvad du har med at gøre

Når vi har besluttet, at mikrotjenester er det rigtige skridt, vil vi gerne give dit system et komplet sundhedstjek for at se, hvordan alt hænger sammen. Vi ser efter langsomme punkter, potentielle afhængighedsproblemer, og hvor alle de kritiske data befinder sig.

Det er risikabelt at springe dette trin over. Hvis du ikke ved, hvad der er under motorhjelmen, kan du ved et uheld komme til at vælte hele systemet som dominobrikker. Ved at kortlægge, hvad der fungerer, hvad der halter, og hvad der kan gå i stykker, skaber vi en smart migrationsplan, der tager fat på de mest kritiske områder først, minimerer risici, undgår nedetid og gør overgangen så gnidningsløs som muligt.

Vælg den rigtige migrationsstrategi

Nu har du sikkert gættet, at jeg ikke er tilhænger af at rive en hel monolit ned fra den ene dag til den anden. Det er for risikabelt, for forstyrrende og som regel ikke stresset værd. I stedet vælger jeg en trinvis tilgang, der giver dig hurtige gevinster, mens du holder din drift stabil.

En af mine yndlingsstrategier er Strangler Fig-mønsteret, som lader dit gamle system og de nye mikrotjenester eksistere side om side, indtil du er klar til den fulde overdragelse.

Branch by Abstraction er praktisk, når du skal foretage ændringer inde i selve monolitten: Vi tilføjer et lag, flytter komponenterne en efter en og sender de gamle ting på pension uden at sprænge tingene i luften.

Hvis pålidelighed er afgørende, holder Parallel Run begge systemer i gang og sammenligner output, før du forpligter dig helt.

Og hvis du ikke kan pille ved monolitten, kan vi med Change Data Capture spore databaseændringer for at holde mikrotjenesterne synkroniserede.

Der er ikke én bedste metode - det hele afhænger af din opsætning. Vores team vælger også, hvilke dele der skal migreres først, og fokuserer på dem, der har den største effekt. Tag f.eks. et e-handelssystem, der håndterer tusindvis af daglige ordrer, eller en dataanalysemotor, der konstant opdateres - de bør flyttes tidligt. På den måde ser du hurtigt de reelle fordele og bevarer en fornuftig drift.

Tilpasning af teams og processer

Inkorporering af mikrotjenester betyder også, at der skal rykkes rundt på, hvordan dine teams arbejder. I stedet for et stort team, der håndterer en monolit, foreslår jeg, at man går over til mindre, tværfunktionelle teams, der hver især ejer en specifik mikrotjeneste. På den måde bliver beslutninger truffet hurtigere, og alle ved præcis, hvad de er ansvarlige for.

Derudover indfører vores eksperter DevOps-principper og automatisering fra dag ét, så udrulningen af nye funktioner går glat og problemfrit.

"At skifte fra monolit til mikrotjenester er ikke bare en teknisk justering - det går ud over udviklingshastigheden, systemstabiliteten og evnen til at skalere. Uden en veltilrettelagt plan kan omkostningerne skyde i vejret, og integrationer kan blive en reel hovedpine. Hos Innowise gør vi overgangen smidig og effektiv, så du kan holde tingene smidige og fokusere på at få din virksomhed til at vokse."

Dmitry Nazarevich

CTO

Trin 2: Identificer og definer mikrotjenester

Når vi har kortlagt migreringsstrategien, er det næste store spørgsmål at finde ud af, hvordan vi bryder monolit op i mikrotjenester uden at skabe rod. Jeg har set virksomheder, der enten forsøger at afkoble alt på én gang eller bare udvælger tilfældige moduler til opdeling. Uanset hvad fører det til spild af tid, brudte afhængigheder og måneder med frustrerende omarbejde.

Min tommelfingerregel: Hold det forretningsfokuseret. Det betyder, at hver Mikroservice skal mappe til en rigtig forretningsfunktion, ikke bare en tilfældig stump kode.

Find naturlige servicegrænser

En af de almindelige faldgruber, vi ser, er at opdele en monolit i tekniske lag. Jeg mener at adskille frontend, backend og database i forskellige tjenester. Det er en sikker måde at ende med tæt koblede, alt for snakkesalige mikrotjenester, der ikke skalerer godt. I stedet bruger vi domænedrevet design (DDD) og afgrænsede kontekster til at opdele tingene på en måde, der rent faktisk giver mening.

Tag en e-handelsplatform. I stedet for at opdele den i en generisk frontend-tjeneste og en backend-tjeneste, opdeler vi den i reelle forretningsfunktioner som ordrebehandling, lagerstyring, betalinger og brugeradministration. Hver tjeneste ejer sin egen logik og sine egne data og er løst koblet, så de kan skaleres uafhængigt af hinanden og udvikle sig uden at ødelægge alt andet.

Prioritering af tjenester til migrering

Jeg er ikke fan af "big bang"-tilgangen. At forsøge at migrere alt på én gang er bare at bede om problemer. I stedet fokuserer vi på, hvad der skal brydes af først ved at se på:

Minimale afhængigheder. Mindre sammenfiltrede moduler er nemmere at tage af uden at ødelægge alt.
Indvirkning på forretningen. Alt, hvad der har med omsætning eller kundeoplevelse at gøre, kommer som regel forrest i køen.
Hyppige ændringer. Tjenester, der opdateres hele tiden, har mest gavn af mikrotjenesternes fleksibilitet.

Denne tilgang hjælper os med at score hurtige gevinster og vise tidlig værdi, hvilket gør det lettere at få opbakning fra teamet. For eksempel kan lønbehandling i et HR-system være en god mikroservice, da den håndterer komplekse, regionsspecifikke beregninger. Men et statisk virksomhedsregister? Det er sandsynligvis ikke det ekstra overhead værd og kan blive i monolitten i et stykke tid.

Undgå den distribuerede monolitfælde

Det sidste, vi ønsker, er at konvertere monolit til mikrotjenester og stadig ende med en masse tjenester, der er for afhængige af hinanden. For at undgå dette skal vi:

Definér klare API'er (REST, gRPC eller event-drevet), så tjenesterne kommunikerer gnidningsløst uden unødvendig frem og tilbage.
Sørg for, at hver tjeneste ejer sine data - ingen delte databaser, der skaber flaskehalse.
Hold afhængighederne på et minimum, så tjenesterne kan opdateres uden at ødelægge alt andet.

Ved at holde tjenesterne løst koblede kan vi opgradere eller ændre dem uden at bekymre os om at ødelægge alt andet.

At få teams med om bord

Som jeg sagde før, så skinner microservices virkelig, når hvert team ejer deres service fra start til slut. Du får hurtigere feedback, mere ansvarlighed og langt mindre frem og tilbage mellem teams. Hos Innowise hjælper vi virksomheder med at sætte deres teams op, så devs, ops, QA og alle andre kan arbejde gnidningsløst sammen.

Bryd din monolit ned i mikrotjenester, og kom let igennem trafikspidser.

Trin 3: Håndtering af data i mikrotjenester

Når vi har delt din monolit op i mikrotjenester, er det første spørgsmål som regel, hvad vi gør med dataene? I en monolitisk opsætning er alt bundet til en stor database, som fungerer, indtil den ikke gør. I et microservices-setup bliver den delte database hurtigt en flaskehals, der gør alting langsommere og gør det umuligt at skalere services uafhængigt af hinanden.

Derfor er jeg fortaler for en decentral datamodel, hvor hver mikrotjeneste ejer sine egne data. Hvis det gøres rigtigt, kan hver tjeneste vokse, tilpasse sig og skalere uden konstant at falde over hinanden.

Drop den monolitiske database

En massiv alt-i-en-database kan virke som den nemme løsning, men i et setup med mikrotjenester bliver den hurtigt en flaskehals. Hver tjeneste har forskellige behov, og at proppe alt ind i en enkelt database skaber bare forhindringer. Det bliver svært at skalere, afhængighederne hober sig op, og selv små ændringer kan forårsage problemer i hele systemet.

Det er derfor, vi deler op i mindre, tjenestespecifikke tjenester, så hver mikrotjeneste:

Kontrollerer sine egne data. Ikke flere konflikter eller utilsigtede ændringer fra andre teams.
Skalerer af sig selv. Tjenesterne behøver ikke at kæmpe om databasens ressourcer.
Kan ændre sig frit. Opdatering af en tjeneste risikerer ikke at ødelægge hele systemet.

På den måde er alting mere fleksibelt, holdene træder ikke hinanden over tæerne, og man undgår den databaseflaskehals, der bremser alle.

Migration af data

At flytte data ud af en monolit er ikke et øjeblik, hvor man bare vender kontakten. Det er risikabelt at rive båndet af, så jeg foretrækker en trinvis tilgang, hvor man bryder det ned trin for trin.

Normalt betyder det, at man opretter nye tabeller eller databaser til hver mikrotjeneste og holder dem synkroniseret med det gamle system ved hjælp af Change Data Capture (CDC) eller dobbeltskrivning. På den måde får hver tjeneste gradvist ejerskab over sine data - ingen nedetid, ingen ubehagelige overraskelser.

At holde data konsistente

I en monolit har du en stor fælles database og ACID-transaktioner, som sørger for, at alt opdateres (eller fejler) sammen. Men med mikrotjenester administrerer hver tjeneste sine egne data, så opdateringer sker ikke øjeblikkeligt på tværs af systemet.

I stedet for direkte opdateringer taler tjenesterne sammen via asynkrone beskeder. Hvis der f.eks. afgives en ordre, udløser ordretjenesten en hændelse, og lagertjenesten lytter med for at justere lagerbeholdningen. Denne opsætning holder tingene kørende, selv hvis en tjeneste midlertidigt går ned.

Det betyder selvfølgelig, at man skal håndtere konsistens på en smart måde. Hos Innowise bruger vi idempotente operationer til at forhindre duplikater, retry-mekanismer til at håndtere hikke og dead-letter køer til at fange fejl. På den måde forbliver dine data nøjagtige, selv når tingene ikke går som planlagt.

Trin 4: Implementering og integration

Okay, nu hvor vi har sat klare servicegrænser og en solid datamigreringsplan, er det tid til at smøge ærmerne op og gøre strategi til handling. Lad os dykke ned i, hvordan vi får det til at ske.

Opbygning af skalerbare, modstandsdygtige mikrotjenester

Vores udviklingsteam bygger mikrotjenester ved hjælp af moderne værktøjer som Spring Boot og Node.js og sørger for, at de er bygget til at skalere og håndtere udfordringer i den virkelige verden. For at holde tingene kørende bruger vi smarte designmønstre som strømafbrydere til at håndtere trafikspidser og graciøs nedbrydning for at forhindre kaskadefejl. På den måde kan resten af dit system køre uden problemer, selv om en tjeneste får problemer.

At holde arven i live (indtil videre)

Lukker du din monolit ned i løbet af natten? Det kommer ikke til at ske. I stedet opretter vi integrationslag ved hjælp af RESTful API'er og meddelelsesmæglere som RabbitMQ eller Apache Kafka for at holde dine nye mikrotjenester og eksisterende systemer synkroniseret. De fungerer som broer, der lader alt kommunikere gnidningsløst uden at bryde arbejdsgange.

Og når det giver mening, inddrager vi også API-gateways for at øge og sikre interaktioner og garantere en gnidningsløs overgang uden nedetid.

Indførelse af containerisering

Vi containeriserer dine mikrotjenester med Docker, så de er hurtige, fleksible og nemme at administrere. Når Kubernetes håndterer orkestreringen, er det en smal sag at skalere op i travle perioder eller udrulle opdateringer på tværs af forskellige miljøer. Denne opsætning holder alting konsistent, forudsigeligt og omkostningseffektivt, så dine IT-operationer aldrig føles som en tilfældighed.

Automatisering med CI/CD-pipelines

Vores team opsætter CI/CD-pipelines med værktøjer som Jenkins, GitLab CI eller CircleCI til automatisk at håndtere test, opbygning og udrulning. Ikke flere manuelle opdateringer eller brandøvelser i sidste øjeblik. Fejl bliver fanget tidligt, udgivelser kommer hurtigere ud, og systemet forbliver bundsolidt.

Lad os bygge et fejltolerant økosystem af mikrotjenester til din virksomhed.

Trin 5: Test, udrulning og overvågning

Uden de rette sikkerhedsforanstaltninger kan selv det bedst designede system blive ramt af flaskehalse, uventede fejl eller bare gå ned på det værst tænkelige tidspunkt. Det er derfor, vores team har en tilgang uden genveje, hvor vi automatiserer alt og fanger problemer, før de bliver til reelle problemer.

Automatiseret testning

Test er ikke bare det sidste trin, det er en del af hele processen. Vores AQA-team bruger automatiserede testsuiter i flere lag til at fange fejl tidligt, så intet glider gennem sprækkerne.

Enhedstest. Hver mikrotjeneste får sit eget tjek med JUnit, Mocha og PyTest. Hvis der er noget galt, opdager vi det med det samme.
Integrationstest. API'er, afhængigheder og dataflow skal alle synkroniseres. Vores eksperter bruger Postman, REST-assured og WireMock til at sikre, at de gør det.
Test på kontrakt. Microservices skal spille efter reglerne. Med Pact holder vi styr på dem og forhindrer ødelagte forbindelser mellem tjenesterne.
End-to-end-testning. Vi gennemgår scenarier fra den virkelige verden - fra brugergrænsefladen og hele vejen til backend - ved hjælp af Selenium, Cypress og Playwright. På den måde fungerer hele systemet som forventet.
Belastnings- og stresstest. Vores team presser systemet til det yderste med JMeter, Gatling og Locust for at se, hvordan det klarer sig under tung trafik.

Risikofri udrulning

Ingen ønsker en dårlig udgivelse, der lægger deres system ned, frustrerer brugerne eller ødelægger omsætningen. Derfor sørger vores team for, at udrulninger er sikre, kontrollerede og klar til at blive rullet tilbage med kamptestede strategier.

Kanariske udgivelser. I stedet for at skifte til alle på én gang, starter vi i det små med at udrulle opdateringer til en lille procentdel af brugerne først. Hvis alt går godt, fortsætter vi. Hvis der er noget galt, retter vores eksperter det, før nogen andre opdager det.

Lad os sige, at en detailvirksomhed ønsker at lancere et pointbaseret loyalitetsprogram, men deres ordresystem er for komplekst til, at det er sikkert at ændre det. En detailvirksomhed vil gerne lancere et pointbaseret loyalitetsprogram, men deres ordresystem er for komplekst til, at det er sikkert at ændre det. For at være på den sikre side tester vi det først med en lille gruppe. Hvis alt går godt, ruller vi det bredere ud.

Blå/grønne implementeringer. Vores team kører to live-miljøer på samme tid:
- Blue (nuværende version): den stabile version, der er live;
- Grøn (opdateret version): den nye udgave, testet og klar til brug.

Når vi er sikre på, at den grønne version er solid, skifter vi trafik med det samme. Hvis noget går galt, skifter vi tilbage til blå. Ingen nedetid, ingen stress.

For eksempel vil en rejseplatform gerne tilføje priser i realtid, men hvis man roder med det gamle system, kan det ødelægge bookingen. I stedet for at gå all-in, går vores team blå-grønt til værks og sender først en lille gruppe brugere til den nye opsætning. Hvis alt er godt, skifter vi alle over. Hvis det går galt, ruller vi straks tilbage.

Funktionsflag og A/B-test. Nogle gange er det ikke det rigtige at rulle ud til 100% brugere. Funktionsflag giver os mulighed for at aktivere eller deaktivere funktioner dynamisk, så vi kan teste i produktionen uden at påvirke alle. Vi bruger også A/B-test til at sammenligne flere funktionsversioner i den virkelige verden, før vi går i gang med en fuld udgivelse.

Forestil dig en e-handelsvirksomhed, der udruller en AI-drevet anbefalingsmotor. I stedet for at slå den til for alle, bruger vi Feature Flags til at aktivere den for tilbagevendende kunder først. Hvis engagementet og salget stiger, udvider vi; hvis ikke, slår vi det fra med det samme.

Samtidig kører vores team A/B-tests, hvor vi sammenligner det gamle system med det nye og sporer nøgletal som indkøbskurvens værdi og konverteringsrater. Disse data hjælper os med at finjustere AI før en lancering i fuld skala.

Proaktiv overvågning og logning i realtid

Microservices producerer tonsvis af data, så det er vigtigt at holde øje med systemets tilstand i realtid. Vores team opsætter overvågning i flere lag med værktøjer som Prometheus, Grafana og New Relic for at spore hastighed, hukommelsesforbrug og fejl. På den måde kan vi spotte problemer, før de bliver en hovedpine. Ved hjælp af ELK Stack, Fluentd og andre samler vi også alle logfiler (dybest set det digitale spor af dine apps) på ét sted, så intet går tabt. Og hvis noget går galt, får vores teknikere automatiske advarsler om det så hurtigt som muligt.

Sikkerhedskopiering og gendannelse af data

Lad os være ærlige, intet system er 100% fejlfrit. Hardware dør, software går ned, og cybertrusler holder aldrig op med at udvikle sig. Derfor er databeskyttelse et must. Så vores team opretter automatiserede backup-strategier, så dine kritiske data forbliver sikre og nemme at gendanne.

Automatiske snapshots. Vi bruger AWS RDS, Google Cloud SQL og Azure Backup til at tage kontinuerlige snapshots af din database. Hvis noget går i stykker, kan du straks rulle tilbage til en stabil version med minimal nedetid.
Geo-redundant lagring. Én backup er ikke nok. Vores eksperter spreder kopier over forskellige datacentre, så selv hvis et af dem går ned eller bliver ramt af et cyberangreb, er dine data stadig sikre og tilgængelige.
Inkrementelle backups og point-in-time recovery. I stedet for at lave én stor backup, der tager lang tid, bruger vi smarte backups, der kun fanger de seneste ændringer. Og med point-in-time recovery kan vi spole din database tilbage til et hvilket som helst øjeblik før et problem, så du undgår utilsigtede sletninger eller datakorruption.
Genopretning efter en katastrofe. En stærk disaster recovery-plan forhindrer små problemer i at udvikle sig til store kriser. Hvis noget svigter, skifter automatiske failover-systemer til en backup, så din virksomhed kan køre videre uden problemer.

Trin 6: Iterativ optimering og skalering

At migrere monolit til mikrotjenester er ikke bare en engangsopgradering, de har brug for løbende pleje for at yde deres bedste. Vi er her i det lange løb og garanterer, at dit setup forbliver smidigt, skalerer problemfrit og håndterer selv de hårdeste belastninger.

Tuning af ydeevne

Vores team holder øje med hver mikrotjeneste, justerer koden, optimerer databaseforespørgsler og udjævner, hvordan tjenesterne kommunikerer for at holde alt kørende hurtigt.

Smart skalering

Ved at analysere trafik- og belastningsmønstre i realtid tilpasser vores specialister dynamisk ressourcerne og sørger for, at tjenester med stor efterspørgsel får det løft, de har brug for, uden at bruge for mange penge.

Kontinuerlig forbedring

Dit system skal vokse med din virksomhed. Vores team sporer performance i realtid, lytter til feedback og foretager smarte justeringer for at holde din arkitektur sikker, effektiv og skudsikker.

Krystalklar dokumentation

Når vi forfiner og udvider dine mikrotjenester, sørger vi for, at alt er veldokumenteret. På den måde går fremtidige opdateringer og migreringer glat, og dit team ved præcis, hvad der foregår.

Fremtidssikr din virksomhedsapp med en smart migrering af mikrotjenester.

Moderniser dine virksomhedsapplikationer med Innowise's løsninger

Migrering fra monolit til mikrotjenester er et strategisk skridt for at opnå bedre smidighed, skalerbarhed og robusthed. Men hvis man kaster sig ud i det uden en fornuftig plan, kan man risikere nedetid, ødelagte arbejdsgange og skyhøje omkostninger. En smart migrering kræver, at man har styr på servicegrænserne, håndterer data korrekt og følger bedste praksis for sikkerhed og implementering.

Hos Innowise hjælper vi virksomheder med at foretage dette skift med selvtillid. Med over 18 år i Modernisering af software og udvikling håndterer vi alt fra at vurdere din opsætning og designe en solid migreringsstrategi til at bygge skalerbare mikrotjenester og forbedre ydeevnen. Vores løsningsarkitekter, DevOps-ingeniører og udviklere bruger velafprøvede metoder til at reducere risikoen og maksimere effekten, så vi kan garantere, at din apps systemer skaleres og udvikles i takt med din virksomhed.

Michael Labutin

Chef for ERP-løsninger

Michael kender ERP ud og ind - fra at vælge det rigtige system til at finde ud af, hvordan det fungerer sammen med resten af din tekniske stak. Han er den, folk henvender sig til, når de har brug for ERP til at løse reelle driftsproblemer, ikke til at skabe nye.

Indholdsfortegnelse

Kontakt os

Book et opkald eller udfyld formularen nedenfor, så vender vi tilbage til dig, når vi har behandlet din anmodning.

Navn

Virksomhed

E-mail

Telefon

Besked

Send os en talebesked

Vedhæft dokumenter

Upload fil

Du kan vedhæfte 1 fil på op til 2 MB. Gyldige filformater: pdf, jpg, jpeg, png.

Ved at klikke på Send accepterer du, at Innowise behandler dine personlige data i henhold til vores Politik for beskyttelse af personlige oplysninger for at give dig relevante oplysninger. Ved at indsende dit telefonnummer accepterer du, at vi kan kontakte dig via taleopkald, sms og beskedapps. Opkalds-, besked- og datatakster kan være gældende.

Du kan også sende os din anmodning
til contact@innowise.com

Hvad sker der nu?

Når vi har modtaget og behandlet din anmodning, vender vi tilbage til dig for at beskrive dine projektbehov og underskriver en NDA for at sikre fortrolighed.

Når vi har undersøgt dine ønsker, behov og forventninger, udarbejder vores team et projektforslag med forslag med arbejdets omfang, teamstørrelse, tids- og omkostningsoverslag.

Vi arrangerer et møde med dig for at diskutere tilbuddet og få detaljerne på plads.

Til sidst underskriver vi en kontrakt og begynder at arbejde på dit projekt med det samme.