ms-ai-architect/skills/ms-ai-advisor/references/architecture/migration-patterns.md

# Migration Patterns - Microsoft AI Platforms

**Last updated:** 2026-06-24 (research via microsoft-learn MCP)
**Category:** Solution Architecture & Advisory
**Status:** Established Practice

---

## Oversikt

Denne referansen dekker vanlige migrasjonsveier mellom Microsoft AI-plattformer og fra eksterne plattformer til Microsoft AI. Målet er å hjelpe arkitekter med å planlegge, gjennomføre og validere migrasjoner på en strukturert måte.

---

## Migrasjonsmatrise

| Fra | Til | Innsats | Risiko | Anbefalt tidslinje |
|-----|-----|---------|--------|-------------------|
| OpenAI API direkte | Azure OpenAI | Lav | Lav | 1-2 uker |
| Azure AI Inference SDK | OpenAI SDK | Lav | Lav | 1-2 uker |
| Azure AI Studio | Microsoft Foundry | Lav-Middels | Lav | 2-4 uker |
| Power Virtual Agents | Copilot Studio | Middels | Middels | 4-8 uker |
| Custom chatbot | Copilot Studio | Middels-Høy | Middels | 8-12 uker |
| AWS Bedrock/SageMaker | Microsoft Foundry | Høy | Høy | 12-16 uker |
| GCP Vertex AI | Microsoft Foundry | Høy | Høy | 12-16 uker |
| Semantic Kernel | Microsoft Agent Framework | Lav-Middels | Lav | 2-4 uker |
| Azure Cognitive Search | Azure AI Search | Minimal | Minimal | Rebranding (ingen kodeendring) |
| Basic RAG | Azure AI Search enhanced RAG | Middels | Lav-Middels | 4-6 uker |

**Forklaring:**
- **Innsats:** Estimert utviklerarbeid (Lav < 40t, Middels 40-160t, Høy > 160t)
- **Risiko:** Sannsynlighet for uventede problemer eller datatap
- **Tidslinje:** Fra planlegging til produksjonsdrift

---

## Detaljerte migrасjonsmønstre

### 1. OpenAI API → Azure OpenAI

**Scenario:** Du bruker OpenAI API direkte (via openai.com) og ønsker å migrere til Azure for bedre kontroll, compliance eller integrering med eksisterende Azure-ressurser.

#### Hvorfor migrere?
- Data residency i EU/Norge for GDPR-compliance
- SLA på 99,9% (vs. best effort hos OpenAI)
- Integrering med Microsoft Entra ID
- Private endpoints og VNet-integrering
- Azure Policy og Cost Management

#### Migrasjonssteg

1. **Forberedelse (Uke 1)**
   - Opprett Azure OpenAI resource i ønsket region
   - Deploy modeller (gpt-4o, gpt-4o-mini, text-embedding-3-large)
   - Konfigurer nettverk (VNet, private endpoint ved behov)
   - Sett opp RBAC roller (Cognitive Services OpenAI User)

2. **Kodeendringer (Uke 1-2)**

   **Før (OpenAI direkte):**
   ```python
   import openai

   client = openai.OpenAI(api_key="sk-...")

   response = client.chat.completions.create(
       model="gpt-4o",
       messages=[{"role": "user", "content": "Hello"}]
   )
   ```

   **Etter (Azure OpenAI):**
   ```python
   import openai

   client = openai.AzureOpenAI(
       api_key="<azure-api-key>",
       api_version="2024-10-21",
       azure_endpoint="https://<resource>.openai.azure.com"
   )

   response = client.chat.completions.create(
       model="gpt-4o-deployment",  # Deployment name, ikke model name
       messages=[{"role": "user", "content": "Hello"}]
   )
   ```

   **Viktige endringer:**
   - `api_version` er påkrevd (bruk en gjeldende stable api_version — verifiser nyeste; `2024-10-21` er et fungerende eksempel, og Foundry anbefaler v1 `/openai/v1/`-surface fremover)
   - `model` parameter er **deployment name** i Azure, ikke OpenAI model name
   - Endpoint URL endres til Azure-format

3. **Testing (Uke 2)**
   - Funksjonstesting: Verifiser at alle API-kall fungerer
   - Ytelsestesting: Sammenlign responstider og throughput
   - Kostnadsanalyse: Sammenlign faktisk forbruk med estimater
   - Failover-testing: Test retry-logikk og error handling

4. **Deployment (Uke 2)**
   - Blue-green deployment anbefales
   - Gradvis trafikk-overgang (canary: 10% → 50% → 100%)
   - Overvåk med Application Insights

#### Rollback-strategi
- Behold OpenAI API key i 30 dager post-migrering
- Implementer feature flag for å bytte mellom providers
- Overvåk error rates og reverter ved > 5% økning

#### Kostnadsforskjeller
- Azure OpenAI: Fast pris per 1K tokens (varierer per region)
- OpenAI direkte: Lik pricing, men uten SLA
- Husk Azure-kostnader for networking (VNet, egress)

#### Vanlige fallgruver
- ❌ Bruke model name i stedet for deployment name
- ❌ Glemme å oppdatere `api_version` parameter
- ❌ Ikke teste rate limits (Azure har andre grenser)
- ❌ Ikke konfigurere retry-logikk for Azure-spesifikke feil

---

### 2. Azure AI Studio → Microsoft Foundry

**Scenario:** Rebranding-migrasjon fra "Azure AI Studio" til "Microsoft Foundry". Dette er primært en portalendring, men med nye funksjoner.

#### Hvorfor migrere?
- Tilgang til nye AI-modeller (DeepSeek, Grok, osv.)
- Unified API (OpenAI v1 format for alle modeller)
- Bedre integrering med Azure AI Services
- Ny portal-opplevelse med bedre UX

#### Migrasjonssteg

1. **Forberedelse (Uke 1-2)**
   - Lag inventarliste over eksisterende AI Studio resources
   - Identifiser avhengigheter (Storage, Key Vault, osv.)
   - Verifiser region-tilgjengelighet for Foundry

2. **Migrasjon (Uke 2-3)**

   **Alternativ A: Behold eksisterende resources**
   - Eksisterende Azure AI resources fungerer direkte i Foundry-portalen
   - Ingen kodeendringer nødvendig
   - Oppdater dokumentasjon til nye portal-URLer

   **Alternativ B: Opprett nye Foundry resources**
   - Opprett ny Foundry resource i Azure Portal
   - Migrer deployments til ny resource
   - Oppdater connection strings i applikasjoner

3. **SDK-oppdatering (Uke 3-4)**

   Hvis du bruker Azure AI Inference SDK, vurder å migrere til OpenAI SDK for bredere modellstøtte:

   **Før (Azure AI Inference SDK):**
   ```python
   from azure.ai.inference import ChatCompletionsClient

   client = ChatCompletionsClient(
       endpoint="https://<resource>.services.ai.azure.com/models",
       credential=AzureKeyCredential(api_key)
   )

   response = client.complete(
       messages=[...],
       model="gpt-4o"  # Valgfritt for single-model endpoints
   )
   ```

   **Etter (OpenAI SDK):**
   ```python
   from openai import OpenAI

   client = OpenAI(
       api_key=api_key,
       base_url="https://<resource>.openai.azure.com/openai/v1/"
   )

   response = client.chat.completions.create(
       model="gpt-4o-deployment",  # Alltid påkrevd
       messages=[...]
   )
   ```

4. **Validering (Uke 4)**
   - Test alle endpoints
   - Verifiser at custom models fungerer
   - Valider at logging og monitoring fortsatt virker

#### Risikofaktorer
- **Lav risiko:** Hovedsakelig UI-endring
- **Vær oppmerksom på:** Custom integrasjoner med AI Studio API
- **Breaking change:** Hvis du bruker AI Inference SDK, må `model` parameter alltid spesifiseres i OpenAI SDK

#### Rollback
- Ikke nødvendig for Alternativ A (samme backend)
- For Alternativ B: Behold gamle resources i 60 dager

---

### 3. Power Virtual Agents → Copilot Studio

**Scenario:** Oppgradering fra Power Virtual Agents (PVA) classic til Copilot Studio unified authoring.

#### Hvorfor migrere?
- Generative AI-funksjoner (boosted conversations)
- Power Fx for variable management
- YAML-basert code view for utviklere
- Event-drevne triggere
- Bedre integrering med M365 Copilot

#### Migrasjonssteg

1. **Eligibilitet-sjekk (Uke 1)**

   **Bots som IKKE kan klones automatisk:**
   - Språk utenom engelsk
   - Handoff til Omnichannel for Customer Service
   - Knowledge Management extensions

   For disse: Manuell re-build nødvendig.

2. **Kloning (Uke 1-2)**

   **I Copilot Studio portal:**
   1. Åpne klassisk bot
   2. På Overview-siden: Klikk "Copy this chatbot"
   3. Velg "Copy and convert this bot"
   4. Vent på kloning (kan ta 5-30 min avhengig av størrelse)
   5. Åpne den nye agenten i Copilot Studio

   **Hva blir klonet:**
   - ✅ Topics bygget i web canvas
   - ✅ Entities og synonymer
   - ✅ Power Automate flows (men må testes!)
   - ❌ Authorization settings (må rekonfigureres)
   - ❌ Channels (må rekonfigureres)
   - ❌ Security settings (må rekonfigureres)
   - ❌ Bot Framework Skills (må reconnectes)

3. **Rekonfigurering (Uke 2-4)**

   **Authorization:**
   - Sett opp OAuth providers på nytt
   - Verifiser at Single Sign-On fungerer

   **Channels:**
   - Rekonfigurer Teams-integrering
   - Sett opp Web Chat på nytt
   - Test alle publiseringskanaler

   **Power Automate:**
   - Test alle flows grundig
   - Verifiser data mappings
   - Sjekk at connections er aktive

4. **Testing (Uke 4-6)**

   **Bruk Copilot Studio Testing Framework:**
   ```yaml
   # test-cases.yaml
   - scenario: "Greeting flow"
     user_input: "Hello"
     expected_topic: "Greeting"
     expected_response_contains: "How can I help"

   - scenario: "Authentication required"
     user_input: "Show my orders"
     expected_auth: true
     expected_topic: "Order Status"
   ```

   **Test-områder:**
   - Funksjonell testing (alle topics)
   - Integrasjonstesting (flows, auth, channels)
   - Ytelsestesting (responstid, concurrent users)
   - Sikkerhets-testing (auth, data leakage)

5. **Deployment (Uke 6-8)**

   **Anbefalt tilnærming:**
   - Publiser ny agent til Test-miljø først
   - Kjør parallelt med gammel bot i 2-4 uker
   - Gradvis overgang av brukere
   - Overvåk brukeropplevelse og feilrate

   **Deployment pipeline-oppdateringer:**
   ```yaml
   # azure-pipelines.yml (før)
   - task: PowerPlatformToolInstaller@0
   - task: PowerPlatformExportSolution@2
     inputs:
       SolutionName: 'PVABot'

   # azure-pipelines.yml (etter)
   - task: PowerPlatformToolInstaller@2
   - task: PowerPlatformExportSolution@2
     inputs:
       SolutionName: 'CopilotStudioAgent'  # Nytt bot ID!
   ```

6. **Post-migration (Uke 8+)**
   - Oppdater dokumentasjon
   - Tren support-team på ny UI
   - Vurder nye funksjoner (boosted conversations, Power Fx)
   - Planlegg oppgradering til generative AI-funksjoner

#### Risikofaktorer
- **Middels risiko:** Custom canvas-komponenter må testes grundig
- **Høy risiko:** Handoff til Omnichannel (krever manuell migrering)
- **Data risiko:** Conversation history bevares ikke automatisk

#### Rollback
- Behold klassisk bot i 90 dager
- Kan reverter trafikk ved kritiske feil
- Vurder parallell drift ved høy business-kritikalitet

#### Kostnadsforskjeller
- Copilot Studio: Copilot Credits-basert forbruk (felles valuta fra 1. sep 2025; erstattet messages/sessions). Eldre lisenser kjøpt før 1. jan 2024 kan fortsatt bruke billed sessions.
- Rater: classic answer 1 · generative answer 2 · agent action 5 · tenant graph grounding 10 Copilot Credits. M365 Copilot-lisensierte brukere belastes ikke (B2E fair use).
- PVA classic: samme Copilot Credits-modell etter konvertering

#### Vanlige fallgruver
- ❌ Ikke teste Power Automate flows grundig nok
- ❌ Glemme å oppdatere deployment pipelines (nytt bot ID)
- ❌ Ikke kommunisere UI-endringer til sluttbrukere
- ❌ Forvente at alle features fungerer identisk (noen oppførselsendringer)

---

### 4. Custom Chatbot → Copilot Studio

**Scenario:** Du har en custom-bygget chatbot (Python/Node.js/C#) og ønsker å migrere til Copilot Studio for enklere vedlikehold og generative AI-funksjoner.

#### Hvorfor migrere?
- Redusert vedlikeholdsbyrde (no-code/low-code)
- Innebygd generative AI (GPT-4o)
- Managed infrastruktur (ingen server-drift)
- Power Platform-integrering (Dataverse, Power Automate)

#### Migrasjonssteg

1. **Kartlegging (Uke 1-2)**

   **Lag inventar over eksisterende funksjoner:**
   ```json
   {
     "intents": [
       {"name": "greeting", "utterances": 150},
       {"name": "faq_product", "utterances": 80},
       {"name": "order_status", "utterances": 120}
     ],
     "entities": [
       {"name": "product_name", "type": "list", "values": 45},
       {"name": "order_id", "type": "regex"}
     ],
     "integrations": [
       {"type": "CRM", "api": "Salesforce REST"},
       {"type": "ERP", "api": "SAP OData"}
     ],
     "channels": ["Web", "Teams", "Slack"]
   }
   ```

2. **Gap-analyse (Uke 2-3)**

   **Sjekk om Copilot Studio støtter dine behov:**

   | Feature | Custom bot | Copilot Studio | Gap? |
   |---------|-----------|----------------|------|
   | NLU | LUIS/Custom | GPT-4o | ✅ Bedre |
   | Custom logic | Python/Node | Power Fx | ⚠️ Mindre fleksibelt |
   | API-integrasjon | REST direkte | Power Automate | ⚠️ Ekstra lag |
   | WebSocket | Ja | Nei | ❌ Må re-designes |
   | Custom UI | Full kontroll | Adaptive Cards | ⚠️ Begrenset |

   **Avgjør:** Kan alle features reimplementeres? Eller trenger du hybrid-løsning?

3. **Design (Uke 3-4)**

   **Map intents til Topics:**
   ```yaml
   # greeting.topic.yaml
   kind: AdaptiveDialog
   beginDialog:
     kind: OnRecognizedIntent
     intent:
       displayName: Greeting
       triggerPhrases:
         - "Hello"
         - "Hi"
         - "Hey there"
     actions:
       - kind: SendActivity
         activity: "Hello! How can I help you today?"
   ```

   **Map entities til Copilot Studio entities:**
   - Simple lists → List entities
   - Regex patterns → Regex entities
   - ML-basert → Generative AI extraction (GPT-4o)

4. **Implementering (Uke 4-10)**

   **Fase 1: Core flows (Uke 4-6)**
   - Re-build top 5 mest brukte intents som Topics
   - Implementer basic entities
   - Sett opp test-miljø

   **Fase 2: Integrasjoner (Uke 6-8)**
   - Bygg Power Automate flows for API-kall
   - Test data mappings
   - Implementer error handling

   **Fase 3: Avansert logikk (Uke 8-10)**
   - Implementer complex workflows med Power Fx
   - Sett opp multi-turn conversations
   - Bygg custom Adaptive Cards for UI

5. **Testing (Uke 10-12)**

   **Regression testing:**
   - Kjør samme test cases som custom bot
   - Sammenlign NLU-accuracy (intent recognition rate)
   - Verifiser at API-integrasjoner fungerer
   - Test edge cases og error scenarios

6. **Deployment (Uke 12-14)**

   **Parallel run:**
   - Deploy Copilot Studio bot til prod
   - Kjør parallelt med custom bot i 2-4 uker
   - Bruk feature flag for å styre hvilken bot som brukes
   - Samle feedback fra brukere

   **Cutover:**
   - Velg dato for full overgang
   - Redirect all trafikk til Copilot Studio
   - Behold custom bot som fallback i 30 dager
   - Decomission custom infrastructure

#### Datamigrering
- **Conversation history:** Ikke automatisk migrerbar
- **Analytics:** Eksporter historikk til Data Lake før decomission
- **User profiles:** Migrer til Dataverse om nødvendig

#### Risikofaktorer
- **Høy risiko:** Custom logic som ikke kan gjenskapes i Power Fx
- **Middels risiko:** Komplekse API-integrasjoner
- **Lav risiko:** Basic FAQ og intent routing

#### Rollback
- Behold custom bot-infrastruktur i 60 dager
- Ha deployment scripts klare for rask re-deploy
- Overvåk metrics tett første 2 uker

#### Kostnadsforskjeller
- **Custom bot:** EC2/App Service ($100-500/mnd) + utviklertid
- **Copilot Studio:** Copilot Credits-basert forbruk, pay-as-you-go eller prepaid packs ($200-1000/mnd avhengig av volum)
- **ROI:** Typisk break-even etter 6-12 mnd grunnet redusert vedlikehold

---

### 5. AWS Bedrock/SageMaker → Microsoft Foundry

**Scenario:** Du kjører LLM-workloads på AWS og ønsker å migrere til Azure for multi-cloud strategi eller bedre integrering med Microsoft 365.

#### Hvorfor migrere?
- Unified AI platform (Microsoft Foundry)
- Integrering med M365 Copilot
- Bedre GDPR-compliance for EU-kunder
- Single-vendor strategi (Azure + Microsoft AI)

#### Migrasjonssteg

1. **Arkitektur-mapping (Uke 1-4)**

   **AWS → Azure ekvivalenter:**

   | AWS Service | Azure Service | Merk |
   |-------------|---------------|------|
   | Bedrock (Claude, Titan) | Azure OpenAI / AI Foundry | Modell-tilgjengelighet varierer |
   | SageMaker Endpoints | Azure ML Endpoints | Custom models |
   | S3 (data) | Blob Storage | Samme objekt-paradigme |
   | Lambda (serverless) | Azure Functions | Samme trigger-modell |
   | Step Functions | Logic Apps / Durable Functions | Workflow orchestration |
   | CloudWatch | Application Insights + Log Analytics | Logging og monitoring |
   | IAM | Microsoft Entra ID + RBAC | Identity management |

2. **Data migration (Uke 2-6)**

   **Strategi A: Batch migration**
   ```bash
   # Bruk AzCopy for stor data
   azcopy copy \
     's3://my-bucket/*' \
     'https://mystorageaccount.blob.core.windows.net/container?[SAS]' \
     --recursive
   ```

   **Strategi B: Continuous sync**
   - Bruk AWS DataSync → Azure Data Factory
   - Sync kun nye data under migreringen
   - Reduserer downtime

3. **Model migration (Uke 4-8)**

   **For managed models (Bedrock):**
   - Map Bedrock models til Azure OpenAI / Foundry ekvivalenter
   - Eksempel: Claude 3 (Bedrock) → GPT-4o (Azure OpenAI)
   - **Viktig:** Test nøye, modellene er ikke identiske!

   **For custom models (SageMaker):**
   - Re-train på Azure ML om nødvendig
   - Eller: Deploy eksisterende model som container på Azure ML
   - Konverter training scripts fra SageMaker til Azure ML SDK v2

   **Før (SageMaker):**
   ```python
   import sagemaker

   estimator = sagemaker.estimator.Estimator(
       image_uri='...',
       role=role,
       instance_count=1,
       instance_type='ml.p3.2xlarge'
   )
   estimator.fit({'training': 's3://bucket/data'})
   ```

   **Etter (Azure ML):**
   ```python
   from azure.ai.ml import MLClient, command

   job = command(
       code='./src',
       command='python train.py',
       environment='azureml:custom-env:1',
       compute='gpu-cluster',
       inputs={'training_data': Input(path='azureml://datastores/data')}
   )
   ml_client.jobs.create_or_update(job)
   ```

4. **Application migration (Uke 6-12)**

   **Endpoint URL-endringer:**
   ```python
   # Før (AWS Bedrock)
   import boto3

   bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')
   response = bedrock.invoke_model(
       modelId='anthropic.claude-v2',
       body=json.dumps({"prompt": "Hello"})
   )

   # Etter (Azure OpenAI)
   from openai import AzureOpenAI

   client = AzureOpenAI(
       api_key=api_key,
       api_version='2024-10-21',
       azure_endpoint='https://<resource>.openai.azure.com'
   )
   response = client.chat.completions.create(
       model='gpt-4o',
       messages=[{"role": "user", "content": "Hello"}]
   )
   ```

   **Oppdater alle:**
   - Endpoint URLs
   - Authentication (AWS IAM → Azure Entra ID)
   - Request/response formats (Bedrock → OpenAI schema)
   - Error handling (ulike feilkoder)

5. **Infrastructure as Code (Uke 8-10)**

   **Hvis du bruker Terraform:**
   ```hcl
   # Før (AWS)
   resource "aws_bedrock_model" "claude" {
     model_id = "anthropic.claude-v2"
   }

   # Etter (Azure)
   resource "azurerm_cognitive_account" "openai" {
     name                = "my-openai"
     resource_group_name = azurerm_resource_group.rg.name
     location            = "eastus"
     kind                = "OpenAI"
     sku_name            = "S0"
   }

   resource "azurerm_cognitive_deployment" "gpt4o" {
     name                 = "gpt-4o"
     cognitive_account_id = azurerm_cognitive_account.openai.id
     model {
       format  = "OpenAI"
       name    = "gpt-4o"
       version = "2024-05-13"
     }
     sku {
       name     = "Standard"
       capacity = 10
     }
   }
   ```

6. **Testing og validering (Uke 10-14)**

   **Performance testing:**
   - Sammenlign latency (AWS vs Azure)
   - Test throughput (requests/second)
   - Valider at rate limits er tilstrekkelige

   **Functional testing:**
   - Re-kjør all existing test suite
   - Verifiser at model outputs er akseptable (kan variere!)
   - Test failover og disaster recovery

7. **Cutover (Uke 14-16)**

   **Blue-green deployment:**
   - Deploy komplett Azure stack (grønn)
   - Kjør parallelt med AWS (blå) i 2 uker
   - Gradvis shift trafikk (10% → 50% → 100%)
   - Overvåk cost, performance, errors
   - Decomission AWS etter successful cutover

#### Identity og tilgangskontroll
- **AWS IAM roles** → **Azure Managed Identities**
- **AWS IAM policies** → **Azure RBAC roles**
- Bruk Azure Policy for governance
- Sett opp Conditional Access for ekstra sikkerhet

#### Kostnadsforskjeller
- **AWS Bedrock:** Per-token pricing (varierer per modell)
- **Azure OpenAI:** Per-token pricing (ofte sammenlignbart)
- **Husk:** Data egress charges (AWS → Azure migrering kan være dyrt)
- **Optimalisering:** Bruk Azure Reservations for 30-70% rabatt

#### Vanlige fallgruver
- ❌ Ikke budsjettere for data egress costs fra AWS
- ❌ Forvente identisk model behavior (Claude ≠ GPT-4o)
- ❌ Ikke teste rate limits før prod-trafikk
- ❌ Glemme å oppdatere monitoring og alerting

#### Rollback-strategi
- Behold AWS infrastructure i 90 dager
- Ha Terraform/IaC klar for rask re-deploy
- Bruk DNS for rask trafikk-switching
- Document rollback prosedyre i detalj

---

### 6. Semantic Kernel → Microsoft Agent Framework

**Scenario:** Du bruker Semantic Kernel (eller AutoGen) for AI-orchestrering og ønsker å migrere til **Microsoft Agent Framework** for multi-agent capabilities.

> **Produktavklaring (viktig):** Microsoft Agent Framework er en **egen, ny multi-språk SDK** — pakke `agent-framework` (importeres som `agent_framework`) i Python, `Microsoft.Agents.AI` i .NET — *ikke* et namespace inni `semantic-kernel`. Den er den **direkte etterfølgeren til BÅDE Semantic Kernel og AutoGen**, bygget av de samme teamene: AutoGens enkle agent-abstraksjoner + Semantic Kernels enterprise-funksjoner (session-state, type-sikkerhet, middleware, telemetri) + nye graf-baserte `Workflow`-er for eksplisitt multi-agent-orkestrering. SK og AutoGen har hver sin offisielle migrasjonsguide (kilder nederst). Ikke forveksle dette med Semantic Kernels *interne* «Agent Framework RC»-migrasjon (som bare endret `ChatCompletionAgent`-konstruktøren innenfor `semantic-kernel`) — det er en SK-intern endring, ikke denne SDK-en.

#### Hvorfor migrere?
- Multi-agent orchestration via typede, graf-baserte workflows (samler SK + AutoGen i én orkestrator)
- Forenklet agent-oppretting — **ingen `Kernel`-objekt**; agenten bygges direkte på en `ChatClient`
- `@tool`-dekoratør (eller bare en Python-funksjon) i stedet for plugin + Kernel-boilerplate
- Alignment med Microsoft 365 Agents SDK (`ChatClientAgent`/`AIAgent`)
- Gradvis migrering mulig — eksisterende SK `KernelFunction` kan gjenbrukes (se kompatibilitet under)

#### Migrasjonssteg

1. **Forberedelse (Uke 1) — installer Agent Framework:**
   ```bash
   # Python — meta-pakken installerer core + vanlige providers
   pip install agent-framework --pre
   # ...eller bare de providerne du trenger (core trekkes inn automatisk):
   pip install --pre agent-framework-foundry agent-framework-openai

   # .NET (provider-pakke; core = Microsoft.Agents.AI)
   dotnet add package Microsoft.Agents.AI.Foundry --prerelease
   ```

2. **Kodeendringer (Uke 1–2) — agent-oppretting uten Kernel:**

   **Før (Semantic Kernel):**
   ```python
   from semantic_kernel.agents import ChatCompletionAgent
   from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion

   agent = ChatCompletionAgent(
       service=AzureChatCompletion(),
       name="Support",
       instructions="Answer in one sentence.",
   )
   ```

   **Etter (Agent Framework):**
   ```python
   from agent_framework import Agent
   from agent_framework.foundry import FoundryChatClient
   from azure.identity import AzureCliCredential

   # Ingen Kernel — agenten bygges direkte på en ChatClient
   agent = Agent(
       client=FoundryChatClient(credential=AzureCliCredential()),
       instructions="You are a helpful assistant",
   )
   # ...eller via convenience-metoden:
   # agent = FoundryChatClient(credential=AzureCliCredential()).as_agent(instructions=...)

   thread = agent.get_new_thread()
   response = await agent.run("Hello world", thread)
   print(response.text)
   ```

   **Nøkkelforskjeller:**
   - **Ingen `Kernel`-objekt** — agenten bygges på en `ChatClient` (Foundry/OpenAI/Azure OpenAI). Dette er hovedforskjellen fra SK.
   - Invokering: `invoke`/`invoke_stream` → `run(..., stream=True/False)`; returtyper `AgentResponse` / `AgentResponseUpdate` (tekst i `response.text`).
   - Thread opprettes av agenten: `thread = agent.get_new_thread()` (ikke manuell type-instansiering).

3. **Tool-registrering (Uke 2) — `@tool` i stedet for plugin + Kernel:**
   ```python
   from typing import Annotated
   from agent_framework import tool

   @tool(name="weather_tool", description="Retrieves weather information")
   def get_weather(location: Annotated[str, "The location to get the weather for."]) -> str:
       """Get the weather for a given location."""
       return f"The weather in {location} is sunny."

   agent = chat_client.as_agent(tools=get_weather)
   ```
   En vanlig Python-funksjon fungerer også direkte (funksjonsnavn → tool-navn, docstring → beskrivelse). Ingen `Plugin`-klasse eller `Kernel` kreves.

   **Kompatibilitet (gradvis migrering):** Eksisterende SK `KernelFunction`-instanser kan konverteres til Agent Framework-tools via `.as_agent_framework_tool` (krever `semantic-kernel` ≥ 1.38). Slik gjenbruker du eksisterende SK-plugins og VectorStore-integrasjoner (Azure AI Search, Qdrant, …) mens du migrerer modul for modul.

4. **Multi-agent orchestration (Uke 2–4):**
   Agent Framework erstatter SKs `AgentGroupChat` med typede, **graf-baserte `Workflow`-er** som ruter data langs edges og aktiverer executors når input er klart — eksplisitt kontroll over kjørestier, checkpointing og human-in-the-loop. For konkrete, kjørbare workflow-eksempler, bruk de offisielle samples (lenker nederst); ikke anta SK `AgentGroupChat`-API-et.

5. **Testing (Uke 3–4)**
   - Valider at konverterte SK `KernelFunction`-tools fungerer
   - Test single-agent `run`/streaming-kontrakten (`AgentResponse` / `AgentResponseUpdate`)
   - Valider multi-agent workflows mot offisielle samples
   - Test error handling og retry-logikk

#### Viktige endringer vs. Semantic Kernel
- **Pakke/imports:** `semantic-kernel` → `agent-framework`; `from semantic_kernel…` → `from agent_framework…`
- **Ingen `Kernel`:** ett `Agent`-grunntype for de fleste tjenester (+ `CopilotStudioAgent`, `A2AAgent`)
- **Invokering:** `invoke`/`invoke_stream` → `run(..., stream=…)`; `AgentResponse` / `AgentResponseUpdate`
- **Tools:** `@kernel_function` + `Plugin` + `Kernel` → `@tool` (eller bare en funksjon)

#### Rollback
- Lav risiko — `semantic-kernel` kan kjøres parallelt under migreringen
- `.as_agent_framework_tool`-broen gir inkrementell migrering, modul for modul

#### Kostnadsforskjeller
- Ingen prising-forskjell i seg selv (samme LLM-forbruk)
- Mulig økning ved multi-agent workflows (flere LLM-kall)

#### Kilder (offisiell migrasjon)
- [Microsoft Agent Framework — overview](https://learn.microsoft.com/agent-framework/overview/)
- [Migrasjon fra Semantic Kernel](https://learn.microsoft.com/agent-framework/migration-guide/from-semantic-kernel/)
- [Migrasjon fra AutoGen](https://learn.microsoft.com/agent-framework/migration-guide/from-autogen/)

---

### 7. Basic RAG → Azure AI Search Enhanced RAG

**Scenario:** Du har en basic RAG-implementasjon (LangChain + vector DB) og ønsker å oppgradere til Azure AI Search for bedre search quality og managed infrastructure.

#### Hvorfor migrere?
- Hybrid search (vector + keyword + semantic)
- Managed service (ingen vector DB å drifte)
- AI-powered document cracking
- Integrering med Azure OpenAI

#### Migrasjonssteg

1. **Forberedelse (Uke 1-2)**

   **Opprett Azure AI Search resource:**
   ```bash
   az search service create \
     --name my-search-service \
     --resource-group my-rg \
     --sku Standard \
     --location norwayeast
   ```

2. **Data indexing (Uke 2-4)**

   **Før (Basic RAG med LangChain):**
   ```python
   from langchain.vectorstores import Chroma
   from langchain.embeddings import AzureOpenAIEmbeddings

   # Manuell document processing
   embeddings = AzureOpenAIEmbeddings()
   vectorstore = Chroma.from_documents(
       documents=docs,
       embedding=embeddings
   )
   ```

   **Etter (Azure AI Search):**
   ```python
   from azure.search.documents import SearchClient
   from azure.search.documents.indexes import SearchIndexClient
   from azure.search.documents.indexes.models import (
       SearchIndex,
       SearchField,
       VectorSearch,
       HnswAlgorithmConfiguration
   )

   # Definer index med vector search
   fields = [
       SearchField(name="id", type="Edm.String", key=True),
       SearchField(name="content", type="Edm.String", searchable=True),
       SearchField(name="content_vector", type="Collection(Edm.Single)",
                  searchable=True, vector_search_dimensions=1536,
                  vector_search_profile_name="vector-profile")
   ]

   vector_search = VectorSearch(
       algorithms=[HnswAlgorithmConfiguration(name="hnsw-config")],
       profiles=[VectorSearchProfile(name="vector-profile",
                                    algorithm_configuration_name="hnsw-config")]
   )

   index = SearchIndex(name="my-index", fields=fields, vector_search=vector_search)
   index_client.create_or_update_index(index)
   ```

3. **Document ingestion (Uke 3-4)**

   **Bruk AI Search indexers for automatisk processing:**
   ```python
   from azure.search.documents.indexes.models import (
       SearchIndexer,
       IndexingSchedule,
       FieldMapping
   )

   # Opprett indexer som crawler Blob Storage
   indexer = SearchIndexer(
       name="blob-indexer",
       data_source_name="blob-datasource",
       target_index_name="my-index",
       schedule=IndexingSchedule(interval="PT2H"),  # Hver 2. time
       field_mappings=[
           FieldMapping(source_field_name="metadata_storage_path",
                       target_field_name="id")
       ]
   )
   ```

4. **Search implementation (Uke 4-5)**

   **Hybrid search (vector + keyword):**
   ```python
   from azure.search.documents.models import VectorizedQuery

   # Generer vector fra query
   query_vector = embeddings.embed_query("What is RAG?")

   # Hybrid search
   results = search_client.search(
       search_text="RAG retrieval augmented generation",  # Keyword
       vector_queries=[VectorizedQuery(
           vector=query_vector,
           k_nearest_neighbors=5,
           fields="content_vector"
       )],
       select=["id", "content"],
       top=5
   )

   for result in results:
       print(f"Score: {result['@search.score']}")
       print(f"Content: {result['content']}")
   ```

5. **RAG integration (Uke 5-6)**

   **Integrer med Azure OpenAI:**
   ```python
   from openai import AzureOpenAI

   # Hent context fra AI Search
   search_results = list(search_client.search(...))
   context = "\n\n".join([r["content"] for r in search_results])

   # Send til LLM med grounding
   client = AzureOpenAI(...)
   response = client.chat.completions.create(
       model="gpt-4o",
       messages=[
           {"role": "system", "content": f"Use this context:\n{context}"},
           {"role": "user", "content": "What is RAG?"}
       ],
       extra_body={
           "data_sources": [{
               "type": "azure_search",
               "parameters": {
                   "endpoint": search_endpoint,
                   "index_name": "my-index",
                   "authentication": {"type": "api_key", "key": search_key}
               }
           }]
       }
   )
   ```

6. **Testing (Uke 6)**
   - Sammenlign search relevance (basic RAG vs AI Search)
   - Test hybrid search vs pure vector search
   - Valider at citations fungerer
   - Performance testing (latency, throughput)

#### Avanserte features
- **Semantic ranking:** Bruk L2 re-ranking for bedre relevance
- **Document cracking:** Automatisk parsing av PDF, Word, etc.
- **Skillsets:** AI-powered enrichment (entity extraction, OCR)

#### Kostnadsforskjeller
- **Basic RAG:** Vector DB hosting ($50-200/mnd) + compute
- **Azure AI Search:** $250-2000/mnd avhengig av SKU og volum
- **ROI:** Break-even ved > 100GB data eller kompleks search logic

#### Rollback
- Behold gammel vector DB i 60 dager
- Kan kjøre parallelt for A/B testing
- Export data fra AI Search ved behov (via REST API)

---

## Data migration best practices

### 1. Pre-migration validation
```python
# Sjekklist før data-migrering
validation_checks = {
    "data_volume": "< 10TB OK for batch, > 10TB vurder streaming",
    "data_format": "Støttes av target platform?",
    "data_quality": "Kjør data profiling først",
    "data_sensitivity": "PII-data? Kryptering nødvendig?",
    "dependencies": "Kartlegg alle data consumers",
    "backup": "Full backup tatt og testet?"
}
```

### 2. Migration strategies

| Strategi | Bruk når | Downtime | Risiko |
|----------|----------|----------|--------|
| Big Bang | < 100GB, lav kritikalitet | 4-24t | Høy |
| Trickle | Continuous sync nødvendig | Minimal | Lav |
| Phased | > 1TB, høy kritikalitet | Per fase | Middels |
| Parallel Run | Business-critical, null downtime | Ingen | Lav |

### 3. Verktøy for datamigrering

**Azure Data Factory:**
```json
{
  "name": "MigrateBlobToAzure",
  "type": "Copy",
  "inputs": [{"referenceName": "AWSBlobDataset"}],
  "outputs": [{"referenceName": "AzureBlobDataset"}],
  "typeProperties": {
    "source": {"type": "BlobSource"},
    "sink": {"type": "BlobSink"},
    "enableStaging": true,
    "parallelCopies": 32
  }
}
```

**AzCopy (for store volumes):**
```bash
# AWS S3 → Azure Blob
azcopy copy \
  's3://source-bucket/*' \
  'https://dest.blob.core.windows.net/container?[SAS]' \
  --recursive \
  --s3-request-concurrency=64
```

---

## Identity og tilgangskontroll migration

### AWS IAM → Azure RBAC

| AWS | Azure | Merk |
|-----|-------|------|
| IAM User | User (Entra ID) | Centralisert identity |
| IAM Role | Managed Identity | Service-to-service auth |
| IAM Policy | RBAC Role | Coarser-grained i Azure |
| Resource Policy | Resource-level RBAC | Lignende konsept |

**Migrasjonssteg:**
1. Map AWS IAM policies til Azure RBAC roles
2. Opprett custom roles for spesialbehov
3. Bruk Managed Identities i stedet for service accounts
4. Implementer Conditional Access for ekstra sikkerhet

---

## Testing og validering checklist

### Pre-migration testing
- [ ] Backup av alle data tatt og verifisert
- [ ] Rollback-prosedyre dokumentert og testet
- [ ] Stakeholders informert om tidsplan
- [ ] DR-plan oppdatert

### Post-migration testing
- [ ] Funksjonell testing (100% feature parity)
- [ ] Performance testing (latency, throughput)
- [ ] Security testing (auth, data encryption)
- [ ] Integrasjonstesting (upstream/downstream systems)
- [ ] User acceptance testing (UAT)
- [ ] Load testing (peak traffic scenarios)
- [ ] Disaster recovery testing (failover, backup restore)

### Monitoring post-migration
- [ ] Error rates < baseline + 5%
- [ ] Latency p95 < baseline + 20%
- [ ] Cost tracking (versus estimate)
- [ ] User feedback collection
- [ ] Incident log (første 30 dager)

---

## Vanlige fallgruver og lessons learned

### Planlegging
❌ **Ikke estimere effort korrekt**
- Multipliser initial estimate med 1.5-2x
- Inkluder buffer for uventede issues

❌ **Ikke involvere stakeholders tidlig nok**
- Inkluder business, security, compliance fra dag 1
- Kommuniser risiko og impact tydelig

### Implementering
❌ **Ikke teste grundig nok før prod**
- Minimum 2 ukers UAT i staging-miljø
- Test edge cases og failure scenarios

❌ **Forsøke å migrere alt samtidig**
- Start med non-critical workloads
- Gradvis overgang reduserer risiko

### Data
❌ **Undervurdere data egress costs**
- AWS → Azure data transfer kan være dyrt ($0.09/GB)
- Budsjetter for dette i advance

❌ **Ikke validere data integrity post-migration**
- Kjør checksums på migrert data
- Sammenlign record counts

### Sikkerhet
❌ **Glemme å oppdatere security policies**
- Revurder IAM/RBAC settings på nytt
- Audit tilganger post-migration

❌ **Ikke kryptere data in-transit**
- Bruk TLS/SSL for all data-overføring
- Spesielt viktig for sensitive data

---

## Effort estimation guidelines

### Estimeringsformel
```
Total effort (timer) =
  (Kartlegging: 10-20%) +
  (Design: 15-25%) +
  (Implementering: 40-50%) +
  (Testing: 20-30%) +
  (Deployment: 5-10%)
```

### Kompleksitetsfaktorer

| Faktor | Multiplikator |
|--------|---------------|
| Data volume > 1TB | +30% |
| Custom ML models | +50% |
| Høy business-kritikalitet | +40% |
| Compliance-krav (GDPR, HIPAA) | +25% |
| Legacy integrasjoner | +35% |
| Multi-region deployment | +60% |

### Eksempel-estimat: AWS Bedrock → Azure OpenAI
```
Base effort: 200 timer
+ Data volume (2TB): +60t (30%)
+ Custom models: +100t (50%)
+ GDPR compliance: +50t (25%)
= Total: 410 timer (~10 uker med 2 FTE)
```

---

## Rollback-plan template

```markdown
# Rollback Plan: [Migration Name]

## Trigger conditions
- Error rate > X%
- Latency p95 > Yms
- Data integrity issues detected
- Critical security vulnerability
- Business decision

## Rollback steps
1. [ ] Stop new traffic to new platform (ETA: 5 min)
2. [ ] Redirect traffic to old platform (ETA: 10 min)
3. [ ] Verify old platform is healthy (ETA: 15 min)
4. [ ] Communicate to stakeholders (ETA: 30 min)
5. [ ] Post-incident review (within 24h)

## Rollback readiness
- [ ] Old platform still running and tested
- [ ] DNS/load balancer configured for quick switch
- [ ] Rollback tested in staging
- [ ] All team members trained on rollback procedure
- [ ] Backup verified and accessible

## Data sync strategy
- How to sync data created in new platform back to old?
- Acceptable data loss window: [X hours/days]
```

---

## Ressurser og verktøy

### Microsoft Learn
- [Azure Migration Guide](https://learn.microsoft.com/azure/cloud-adoption-framework/migrate/)
- [Copilot Studio Migration](https://learn.microsoft.com/microsoft-copilot-studio/unified-authoring-conversion)
- [Microsoft Foundry Documentation](https://learn.microsoft.com/azure/foundry/)

### Verktøy
- **Azure Migrate:** Assessment og migrering av workloads
- **Azure Data Factory:** Data ingestion og ETL
- **AzCopy:** Bulk data transfer
- **Azure DevOps:** CI/CD for migrations
- **Terraform:** Infrastructure as Code for både AWS og Azure

### Community
- [Microsoft Tech Community](https://techcommunity.microsoft.com/)
- [Azure AI Discord](https://discord.gg/azureai)
- [Power Platform Community](https://powerusers.microsoft.com/)

---

## Oppsummering: Velg riktig migrasjonsstrategi

| Scenario | Anbefalt tilnærming | Timeline |
|----------|---------------------|----------|
| Proof of Concept | Big Bang (rask migrering) | 2-4 uker |
| Produksjon (lav traffic) | Phased migration | 6-12 uker |
| Produksjon (høy traffic) | Parallel run → gradual cutover | 12-16 uker |
| Business-critical | Parallel run (extended) → validert cutover | 16-24 uker |

**Husk:** Beste praksis er alltid å starte smått, teste grundig, og skalere gradvis. Ingen migrering er for liten til å planlegges ordentlig.