FAQ Migrationen
Von Attain/Financials bis Business Central – mit voller Datenbank, Eigenentwicklungen und Zeitdruck.
Wenn du dich fragst, ob eure NAV-Version „zu alt“ ist: nein. Entscheidend ist nicht das Alter – sondern eine saubere Upgrade‑ und Migrationsstrategie.
Kurz gesagt: Ich mache alte NAV-Systeme upgrade-fähig, bevor die eigentliche Migration startet. Das senkt Risiken, reduziert Merges und macht C/AL→AL planbar – selbst bei tausenden Eigenobjekten.
Was ist das Ziel?
- Business Central als stabile Zielplattform (On‑Prem oder SaaS – je nach Rahmenbedingungen).
- Minimale Downtime durch Probeläufe, Cutover‑Plan und belastbare Checklisten.
- Weniger Daten, weniger Risiko, weniger Aufwand – ohne die kaufmännische Nachvollziehbarkeit zu zerstören.
- Customizing zukunftsfähig machen: weg von „Monolith‑C/AL“, hin zu Events/Extensions und klaren Schichten.
Der typische Fahrplan (praxisbewährt)
- Quick‑Assessment (1–2 Tage): Version, Datenvolumen, Objektlandschaft, Add‑ons, Integrationen, kritische Prozesse.
- Upgrade‑Pfad definieren: „Direkt“ vs. „Staged Upgrade“ (z. B. Attain → NAV2009 → NAV2018/BC14 → BC aktuell) – mit klaren Stop‑Points.
- Data‑Reduction: Datumskomprimierung, Archivierungsstrategie, gezielte Bereinigung (z. B. alte Log‑/Buffer‑Tabellen), damit der Move schneller & günstiger wird.
- Transformation des Customizings: Refactoring, Event‑Patterns, Trennung von Geschäftslogik/Integration/Reporting.
- Migrationsläufe: Microsoft‑Tools, RapidStart/Configuration Packages, oder SQL‑Skripte – je nachdem, was für eure Daten/Struktur sinnvoll ist.
- Tests & Cutover: Rehearsal‑Migrationen, Abnahme nach Prozess‑Checkliste, Go‑Live‑Begleitung.
Die wichtigsten Fragen – klar beantwortet
„Wir sind auf Financials oder Attain … geht das überhaupt?“
Ja. Genau da beginnt oft der größte Hebel. Ich bringe sehr alte Versionen zunächst in einen upgrade‑fähigen Zustand (Objekt‑Bereinigung, Daten‑/Code‑Konvertierungen, Zwischenversionen, kontrollierte Tests) – bis eine saubere Basis für Business Central steht.
„Unsere Datenbank ist riesig. Wird das nicht unbezahlbar?“
Große Datenbanken sind häufig nicht „wertvoll groß“, sondern „historisch groß“. Mit Datumskomprimierung (G/L, Debitor/Kreditor, Wertposten usw.), Archivierungslogik und gezielter Bereinigung lässt sich das Volumen oft massiv reduzieren. Ergebnis: kürzere Migrationsläufe, weniger Fehlerquellen, weniger Infrastruktur‑Kosten.
„Microsoft‑Migrationstools oder SQL‑Skripte – was ist besser?“
Es gibt kein Dogma – nur passende Werkzeuge. Standard‑Tools sind gut, wenn Strukturen „nah am Standard“ sind. Bei komplexen Historien, Spezialtabellen oder Performance‑Themen sind SQL‑Skripte oft schneller und kontrollierbarer. In der Praxis kombiniere ich beides: Standard wo möglich, SQL wo sinnvoll.
„Wir haben tausende Eigenobjekte. Wird das in AL nicht ein Albtraum?“
Es wird nur dann ein Albtraum, wenn man es ohne Plan angeht. Der Schlüssel ist Entkopplung: Logik aus alten Monolithen herauslösen, in Events/Subscriber auslagern, klare Schichten bilden – damit die C/AL→AL‑Transformation planbar wird. Ich nutze dabei Refactoring‑Strategien, die sich in der Realität bewährt haben (nicht nur „Best Practices“ auf Papier).
„Kann man moderne BC‑Funktionen/Events in ältere Versionen zurückbringen?“
Teilweise ja – in Form gezielter Backports oder „Downgrade‑Patterns“, damit ihr bereits vor der eigentlichen Migration Code in Events auslagern könnt. Das macht spätere Upgrades deutlich leichter, weil die Architektur schon vorher „BC‑kompatibler“ wird.
Praxisbeispiel (real, messbar): BC25‑Event nach NAV 2018 zurückbringen
Wenn du in einem Gespräch sofort sehen willst, ob jemand Migration wirklich kann, dann achte auf so etwas: In Business Central 25 existiert in Codeunit 80 ein Integration‑Event, das in NAV 2018 nicht existiert. Genau an solchen Stellen sitzt beim Kunden oft „Custom Code im Standard“ – und genau das macht Upgrades teuer.
Event (BC25): OnProcessPostingLinesOnBeforePostDropOrderShipment
Idee: Vor dem Posten einer Drop‑Shipment‑Logik einen stabilen Hook anbieten – damit Individualcode als Subscriber ausgelagert werden kann.
1) BC25: Publisher existiert
[IntegrationEvent(false, false)]
local procedure OnProcessPostingLinesOnBeforePostDropOrderShipment(
SalesHeader: Record "Sales Header";
TotalSalesLine: Record "Sales Line")
begin
end;
2) NAV 2018: Publisher nachziehen (Codeunit 80)
In NAV 2018 legst du in Codeunit 80 eine leere Function mit identischer Signatur an und aktivierst sie als Publisher.
LOCAL PROCEDURE OnProcessPostingLinesOnBeforePostDropOrderShipment@50000(
SalesHeader@1000 : Record "Sales Header";
TotalSalesLine@1001 : Record "Sales Line");
BEGIN
END;
Function‑Properties (C/SIDE):
- EventPublisher = Yes
- EventPublisherType = Integration (falls verfĂĽgbar)
3) Event an der richtigen Stelle auslösen
Der Aufruf kommt direkt vor der Stelle, an der „Drop Order Shipment“ gepostet wird (dort, wo früher oft kundenspezifischer Code stand):
// ... kurz bevor Drop Order Shipment gepostet wird:
OnProcessPostingLinesOnBeforePostDropOrderShipment(SalesHeader, TotalSalesLine);
// danach läuft Standard weiter (Post Drop Shipment / Shipment-Logik)
4) Custom Code raus aus dem Standard: Subscriber‑Codeunit
Jetzt legst du eine neue Kunden‑Codeunit (z. B. 50080) an und abonnierst das Event.
Der ehemalige Standard‑Patch wandert vollständig in den Subscriber.
LOCAL PROCEDURE Handle_OnProcessPostingLinesOnBeforePostDropOrderShipment@50000(
SalesHeader@1000 : Record "Sales Header";
TotalSalesLine@1001 : Record "Sales Line");
BEGIN
// >>> Hier liegt jetzt der kundenspezifische Code (ehemals in CU80) <<<
// Validierungen, Logging, Zusatzlogik, Nebenbuchungen, etc.
END;
Function‑Properties (C/SIDE):
- EventSubscriber = Yes
- EventSubscriberObjectType = Codeunit
- EventSubscriberObjectId = 80
- EventSubscriberFunction = OnProcessPostingLinesOnBeforePostDropOrderShipment
Warum das so stark ist
- Upgrades werden langweilig: weniger Merge‑Konflikte, weil Standard wieder Standard ist.
- AL‑Transformation wird planbar: Event/Subscriber‑Struktur entspricht dem BC‑Prinzip – du nimmst sie „automatisch“ mit.
- Du gewinnst Geschwindigkeit: weniger Analyse‑Zeit, weniger Reparatur‑Schleifen, sauberere Tests.
Genau solche Backports sind mein Alltag. Wenn du mir Version + DB‑Größe + grobe Objektanzahl gibst, kann ich sehr schnell sagen, welcher Upgrade‑Pfad für euch der schnellste und risikoärmste ist – inkl. messbarer Hebel durch Data‑Reduction und Refactoring.
„Wie schnell bekommen wir Klarheit?“
Sehr schnell. Nach dem Assessment kann ich dir sauber sagen:
- welcher Upgrade‑Pfad realistisch ist,
- wo die größten Risiken liegen,
- wie ihr Zeit und Kosten über Data‑Reduction und Refactoring spürbar senkt,
- und wie wir die Migration in kontrollierbaren Etappen liefern.
Wenn du jetzt nur einen Schritt machst …
Schick mir eine kurze Nachricht (Version, Datenbankgröße, grobe Anzahl Eigenobjekte, Ziel: SaaS oder On‑Prem). Du bekommst keine Floskeln, sondern eine klare, belastbare Einschätzung: Upgrade‑Pfad, Risiken, Data‑Reduction‑Hebel und ein Vorgehen, das in der Praxis funktioniert.
FAQ Migrations
From Attain/Financials to Business Central – even with a full database, heavy customizations and time pressure.
If you’re wondering whether your NAV version is “too old”: it isn’t. What matters is a clean upgrade path and a migration strategy you can execute.
In short: I make legacy NAV systems upgrade-ready before the actual migration starts. That reduces risk, eliminates merge pain, and turns C/AL→AL into a structured, predictable process — even with thousands of custom objects.
What’s the goal?
- Business Central as a stable target (On‑Prem or SaaS – based on your constraints).
- Minimal downtime using rehearsal runs, a cutover plan, and checklist‑driven validation.
- Less data, less risk, less effort – without breaking financial traceability.
- Future‑proof customization: from monolithic C/AL to event‑driven extensions and clean layers.
A proven roadmap
- Quick assessment (1–2 days): version, data volume, object landscape, add‑ons, integrations, critical processes.
- Define the upgrade path: direct vs. staged (e.g., Attain → NAV2009 → NAV2018/BC14 → latest BC) with clear stop points.
- Data reduction: date compression, archiving strategy, targeted cleanup (e.g., legacy log/buffer tables) to cut time and cost.
- Modernize customization: refactoring, event patterns, separation of business logic / integration / reporting.
- Migration runs: Microsoft tools, RapidStart/config packages, or SQL scripts – depending on what fits your structures.
- Testing & cutover: rehearsal migrations, process‑based acceptance, go‑live support.
Key questions – straight answers
“We’re on Financials or Attain … is this even possible?”
Yes. That’s often where the biggest leverage starts. I bring very old versions into an upgrade‑ready state (object cleanup, data/code conversions, intermediate versions, controlled testing) until Business Central becomes a clean and safe next step.
“Our database is huge. Won’t this be extremely expensive?”
Large databases are often “historically large” rather than “business‑valuable large”. With date compression (G/L, customer/vendor, value entries, etc.), archiving logic and targeted cleanup, volume can often be reduced significantly. Result: faster migration runs, fewer failure points, lower infrastructure cost.
“Microsoft migration tools or SQL scripts – which is better?”
There is no dogma – only the right tool for your situation. Standard tools are great if your structures are close to standard. For complex histories, special tables or performance constraints, SQL scripts can be faster and more controllable. In practice, I combine both: standard where possible, SQL where it adds value.
“We have thousands of custom objects. Won’t AL be a nightmare?”
It only becomes a nightmare without a plan. The key is decoupling: extract logic from monoliths, move it into events/subscribers, and build clear layers – so the C/AL→AL transformation becomes manageable. I use refactoring strategies that are proven in real projects (not just theory).
“Can modern BC features/events be brought back to older versions?”
In parts, yes – via targeted backports / compatibility patterns, so you can start moving custom logic into events before the final migration. This makes later upgrades much easier because the architecture is already more “BC‑ready”.
Real example (practical, measurable): Backporting a BC25 event to NAV 2018
If you want a quick indicator whether someone truly understands migrations, look for this: In Business Central 25, Codeunit 80 provides an IntegrationEvent that does not exist in NAV 2018. That’s exactly where customer code often lives “inside the standard” — and that’s what makes upgrades expensive.
Event (BC25): OnProcessPostingLinesOnBeforePostDropOrderShipment
Idea: provide a stable hook right before posting drop shipment logic — so customer code can be moved into a subscriber.
1) BC25: Publisher exists
[IntegrationEvent(false, false)]
local procedure OnProcessPostingLinesOnBeforePostDropOrderShipment(
SalesHeader: Record "Sales Header";
TotalSalesLine: Record "Sales Line")
begin
end;
2) NAV 2018: Add the publisher (Codeunit 80)
In NAV 2018, you create an empty function with the same signature and turn it into a publisher via function properties.
LOCAL PROCEDURE OnProcessPostingLinesOnBeforePostDropOrderShipment@50000(
SalesHeader@1000 : Record "Sales Header";
TotalSalesLine@1001 : Record "Sales Line");
BEGIN
END;
Function properties (C/SIDE):
- EventPublisher = Yes
- EventPublisherType = Integration (if available)
3) Trigger the event at the correct point
The call goes right before posting “Drop Order Shipment” (often the exact spot where legacy custom code used to sit):
// ... right before posting Drop Order Shipment:
OnProcessPostingLinesOnBeforePostDropOrderShipment(SalesHeader, TotalSalesLine);
// then the standard posting logic continues
4) Move custom code out of the standard: subscriber codeunit
Now you create a dedicated customer codeunit (e.g. 50080) and subscribe to the event.
The former standard patch moves entirely into the subscriber.
LOCAL PROCEDURE Handle_OnProcessPostingLinesOnBeforePostDropOrderShipment@50000(
SalesHeader@1000 : Record "Sales Header";
TotalSalesLine@1001 : Record "Sales Line");
BEGIN
// >>> Customer-specific logic that used to be in CU80 now lives here <<<
// validations, logging, additional logic, side postings, etc.
END;
Function properties (C/SIDE):
- EventSubscriber = Yes
- EventSubscriberObjectType = Codeunit
- EventSubscriberObjectId = 80
- EventSubscriberFunction = OnProcessPostingLinesOnBeforePostDropOrderShipment
Why this matters
- Upgrades become predictable: fewer merge conflicts because the standard is clean again.
- AL conversion becomes structured: the event/subscriber pattern matches Business Central architecture.
- You gain speed: less analysis time, fewer repair cycles, cleaner testing.
This is what I do in real projects. Give me your version, DB size and a rough object count and I can quickly outline the fastest, safest upgrade path — including measurable levers via data reduction and refactoring.
“How fast can we get clarity?”
Very fast. After the assessment, I can clearly tell you:
- which upgrade path is realistic,
- where the real risks are,
- how to reduce time/cost via data reduction and refactoring,
- and how we deliver the migration in controlled stages.
If you do just one thing now …
Send me a short message (version, database size, rough number of custom objects, target: SaaS or On‑Prem). You’ll get a clear, project‑ready assessment: upgrade path, risks, data reduction levers, and a plan that works in the real world.