Kjell Tore Guttormsen baa2d0220b feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command

Add /ultraresearch-local for structured research combining local codebase
analysis with external knowledge via parallel agent swarms. Produces research
briefs with triangulation, confidence ratings, and source quality assessment.

New command: /ultraresearch-local with modes --quick, --local, --external, --fg.
New agents: research-orchestrator (opus), docs-researcher, community-researcher,
security-researcher, contrarian-researcher, gemini-bridge (all sonnet).
New template: research-brief-template.md.

Integration: --research flag in /ultraplan-local accepts pre-built research
briefs (up to 3), enriches the interview and exploration phases. Planning
orchestrator cross-references brief findings during synthesis.

Design principle: Context Engineering — right information to right agent at
right time. Research briefs are structured artifacts in the pipeline:
ultraresearch → brief → ultraplan --research → plan → ultraexecute.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-04-08 08:58:35 +02:00

35 KiB

Raw Blame History

Migration Patterns - Microsoft AI Platforms

Last updated: 2026-01 (research via microsoft-learn MCP)

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	Azure AI 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	Azure AI Foundry	Høy	Høy	12-16 uker
GCP Vertex AI	Azure AI 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

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)

Kodeendringer (Uke 1-2)

Før (OpenAI direkte):

import openai

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

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

Etter (Azure OpenAI):

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 nyeste stable: 2024-10-21)
model parameter er deployment name i Azure, ikke OpenAI model name
Endpoint URL endres til Azure-format

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
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 → Azure AI Foundry

Scenario: Rebranding-migrasjon fra "Azure AI Studio" til "Azure AI 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

Forberedelse (Uke 1-2)
- Lag inventarliste over eksisterende AI Studio resources
- Identifiser avhengigheter (Storage, Key Vault, osv.)
- Verifiser region-tilgjengelighet for Foundry
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

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):

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):

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=[...]
)

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

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.
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)
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

Testing (Uke 4-6)

Bruk Copilot Studio Testing Framework:

# 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)

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:

# 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!

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: Per session pricing (billed sessions)
PVA classic: Per session pricing (samme modell)
Nytt: Generative AI-funksjoner har tilleggskostnad (per message)

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

Kartlegging (Uke 1-2)

Lag inventar over eksisterende funksjoner:

{
  "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"]
}

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?

Design (Uke 3-4)

Map intents til Topics:

# 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)

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
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
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: Per session pricing ($200-1000/mnd avhengig av volum)
ROI: Typisk break-even etter 6-12 mnd grunnet redusert vedlikehold

5. AWS Bedrock/SageMaker → Azure AI 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 (Azure AI Foundry)
Integrering med M365 Copilot
Bedre GDPR-compliance for EU-kunder
Single-vendor strategi (Azure + Microsoft AI)

Migrasjonssteg

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

Data migration (Uke 2-6)

Strategi A: Batch migration
```
# 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

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):

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):

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)

Application migration (Uke 6-12)

Endpoint URL-endringer:

# 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)

Infrastructure as Code (Uke 8-10)

Hvis du bruker Terraform:

# 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
  }
}

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
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 for AI orchestration og ønsker å oppgradere til Microsoft Agent Framework for multi-agent capabilities.

Hvorfor migrere?

Multi-agent orchestration (AutoGen integrering)
Bedre plugin management
Unified API for agents
Alignment med Microsoft 365 Agents SDK

Migrasjonssteg

Forberedelse (Uke 1)

Installer Agent Framework:

# Python
pip install semantic-kernel[agents] --upgrade

# .NET
dotnet add package Microsoft.SemanticKernel.Agents

Kodeendringer (Uke 1-2)

Før (Semantic Kernel):

from semantic_kernel import Kernel
from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion

kernel = Kernel()
kernel.add_service(
    AzureChatCompletion(
        deployment_name="gpt-4o",
        endpoint=endpoint,
        api_key=api_key
    )
)

# Kjør funksjon
result = await kernel.invoke(
    function_name="MyPlugin-MyFunction",
    input="Hello world"
)

Etter (Agent Framework):

from semantic_kernel.agents import ChatCompletionAgent
from semantic_kernel.agents import AgentThread
from semantic_kernel import Kernel

# Opprett agent (erstatter kernel)
agent = ChatCompletionAgent(
    service_id="agent-gpt4o",
    kernel=kernel,
    name="MyAgent",
    instructions="You are a helpful assistant"
)

# Opprett thread (erstatter direkte invoke)
thread = AgentThread()

# Få respons
async for response in agent.invoke(
    thread=thread,
    messages=[{"role": "user", "content": "Hello world"}]
):
    print(response.message.content)

Nøkkelforskjeller:

Kernel object eksisterer fortsatt, men wrappes av Agent
invoke() returnerer nå AgentResponseItem (ikke bare string)
Threads må håndteres eksplisitt (bedre for multi-turn conversations)

Plugin migration (Uke 2)

Semantic Kernel plugins fungerer fortsatt!

# Register plugin (samme som før)
kernel.add_plugin(
    MyPlugin(),
    plugin_name="MyPlugin"
)

# Agent Framework bruker samme plugins automatisk
agent = ChatCompletionAgent(
    kernel=kernel,  # Plugins er tilgjengelige via kernel
    name="PluginAgent"
)

Multi-agent orchestration (Uke 2-4)

Nytt i Agent Framework:

from semantic_kernel.agents import AgentGroupChat

# Opprett flere agents
researcher = ChatCompletionAgent(
    kernel=kernel,
    name="Researcher",
    instructions="You research topics thoroughly"
)

writer = ChatCompletionAgent(
    kernel=kernel,
    name="Writer",
    instructions="You write engaging content"
)

# Orchestrer agents
chat = AgentGroupChat(
    agents=[researcher, writer],
    selection_strategy=SequentialSelectionStrategy()
)

# Kjør multi-agent workflow
async for response in chat.invoke(
    messages=[{"role": "user", "content": "Write article about AI"}]
):
    print(f"{response.agent.name}: {response.message.content}")

Testing (Uke 3-4)
- Test at eksisterende Semantic Kernel plugins fungerer
- Valider multi-agent workflows
- Verifiser at thread state håndteres korrekt
- Test error handling og retry logic

Breaking changes (Python 1.26.1+)

❌ agent.chat_history er fjernet → Bruk thread i stedet
❌ Import paths endret: semantic_kernel.agents.autogen → semantic_kernel.agents
⚠️ invoke() returnerer AgentResponseItem, ikke ChatMessageContent direkte

Rollback

Minimal risiko (Semantic Kernel fortsatt tilgjengelig)
Kan kjøre begge frameworks parallelt
Pinne til eldre versjon ved behov: semantic_kernel==1.25.0

Kostnadsforskjeller

Ingen prising-forskjell (samme LLM-forbruk)
Mulig økning ved multi-agent workflows (flere LLM-kall)

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

Forberedelse (Uke 1-2)

Opprett Azure AI Search resource:

az search service create \
  --name my-search-service \
  --resource-group my-rg \
  --sku Standard \
  --location norwayeast

Data indexing (Uke 2-4)

Før (Basic RAG med LangChain):

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):

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)

Document ingestion (Uke 3-4)

Bruk AI Search indexers for automatisk processing:

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")
    ]
)

Search implementation (Uke 4-5)

Hybrid search (vector + keyword):

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']}")

RAG integration (Uke 5-6)

Integrer med Azure OpenAI:

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}
            }
        }]
    }
)

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

# 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:

{
  "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):

# 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:

Map AWS IAM policies til Azure RBAC roles
Opprett custom roles for spesialbehov
Bruk Managed Identities i stedet for service accounts
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

# 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

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

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.

35 KiB Raw Blame History Unescape Escape

Migration Patterns - Microsoft AI Platforms

Oversikt

Migrasjonsmatrise

Detaljerte migrасjonsmønstre

1. OpenAI API → Azure OpenAI

Hvorfor migrere?

Migrasjonssteg

Rollback-strategi

Kostnadsforskjeller

Vanlige fallgruver

2. Azure AI Studio → Azure AI Foundry

Hvorfor migrere?

Migrasjonssteg

Risikofaktorer

Rollback

3. Power Virtual Agents → Copilot Studio

Hvorfor migrere?

Migrasjonssteg

Risikofaktorer

Rollback

Kostnadsforskjeller

Vanlige fallgruver

4. Custom Chatbot → Copilot Studio

Hvorfor migrere?

Migrasjonssteg

Datamigrering

Risikofaktorer

Rollback

Kostnadsforskjeller

5. AWS Bedrock/SageMaker → Azure AI Foundry

Hvorfor migrere?

Migrasjonssteg

Identity og tilgangskontroll

Kostnadsforskjeller

Vanlige fallgruver

Rollback-strategi

6. Semantic Kernel → Microsoft Agent Framework

Hvorfor migrere?

Migrasjonssteg

Breaking changes (Python 1.26.1+)

Rollback

Kostnadsforskjeller

7. Basic RAG → Azure AI Search Enhanced RAG

Hvorfor migrere?

Migrasjonssteg

Avanserte features

Kostnadsforskjeller

Rollback

Data migration best practices

1. Pre-migration validation

2. Migration strategies

3. Verktøy for datamigrering

Identity og tilgangskontroll migration

AWS IAM → Azure RBAC

Testing og validering checklist

Pre-migration testing

Post-migration testing

Monitoring post-migration

Vanlige fallgruver og lessons learned

Planlegging

Implementering

Data

Sikkerhet

Effort estimation guidelines

Estimeringsformel

Kompleksitetsfaktorer

Eksempel-estimat: AWS Bedrock → Azure OpenAI

Rollback-plan template

Ressurser og verktøy

Microsoft Learn

Verktøy

Community

Oppsummering: Velg riktig migrasjonsstrategi

35 KiB

Raw Blame History