FortiGate Configuration Migration Uganda
A structured service for moving an existing firewall configuration to a target FortiGate while controlling model, FortiOS, interface, policy and cutover risk.
The migration may be FortiGate-to-FortiGate or from a supported third-party firewall. Fortinet provides FortiConverter workflows for configuration conversion, but the practical outcome still depends on clean source data, correct interface mapping, licensing or entitlement, target-device readiness and a deliberate validation plan. FourTeck helps Uganda buyers turn those variables into a usable migration scope before the change window begins.
Request Migration Quote
Review migration requirements
What a FortiGate migration actually needs to preserve
A firewall migration is not simply a file copy between appliances. The source configuration expresses how the existing business network works: interfaces connect to WAN, LAN, DMZ, servers and branch links; routes direct traffic; address objects represent hosts and subnets; policies decide what can communicate; network address translation changes packet addressing; VPNs link users and sites; security profiles inspect traffic; and administrative settings determine how the platform is controlled. A useful migration preserves the intent of those functions while translating them into a configuration that the target FortiGate can understand and operate safely.
Fortinet describes FortiConverter Service as a one-time service that can convert an older FortiOS or supported third-party firewall configuration to FortiOS for a new FortiGate. For supported FortiGate-to-FortiGate workflows, current FortiOS documentation also provides a migration path directly through the FortiGate graphical interface when the relevant eligibility conditions are met. That automation can remove a large amount of repetitive translation, but it does not eliminate the need to understand the network being moved.
Uganda organisations usually approach this work during a hardware refresh, capacity upgrade, end-of-life replacement, branch standardisation project, security redesign or transition from another firewall platform. The buyer may be a bank branch, school, clinic, NGO, professional office, hotel, retailer, manufacturer, logistics operation or public-sector environment. The common requirement is continuity: users should retain the access they need, prohibited traffic should remain prohibited, VPN relationships must be accounted for, and the target device should be ready for the traffic and inspection load expected after cutover.
FourTeck can assist by gathering the source and target details, identifying migration dependencies, reviewing conversion boundaries, preparing a quote scope and helping the customer decide what should be copied, translated, redesigned or deliberately left behind. The most important early decision is whether the project is a like-for-like configuration migration or an opportunity to change architecture at the same time. Combining a firewall replacement with a major network redesign is possible, but it increases the number of variables that must be tested.
Why a controlled migration is better than rebuilding under pressure
Preserve policy intent
Existing rules often embody years of business decisions. Converting address objects, services, routing logic and policy relationships provides a structured starting point instead of asking an engineer to remember every exception during a maintenance window. The business value is continuity: access that is genuinely required can be carried forward and reviewed rather than recreated from memory.
Reduce manual translation risk
FortiConverter is designed to translate configurations using defined conversion logic rather than relying only on manual re-entry. That can reduce typographical errors, missed objects and inconsistent rule recreation. It does not remove the need for review, but it gives the engineer a more systematic base from which to validate the target configuration.
Make the cutover measurable
A migration plan can define what must work after the new firewall starts: internet access, DNS, business applications, site-to-site VPNs, remote access, inbound services, branch routes, management reachability and logging. This converts a vague “firewall swap” into a set of testable acceptance criteria that IT teams can verify before declaring the project complete.
Expose legacy dependencies before they become outages
Older configurations often contain retired objects, duplicate rules, stale VPN peers or assumptions tied to interface names and hardware behavior. Reviewing these items before conversion helps the buyer distinguish between something that must be preserved and something that should be retired. That discussion is far safer before the change than during troubleshooting after the new device is live.
Support model and FortiOS changes deliberately
Cross-model migration can require interface remapping and changes to constructs such as hardware switches. Fortinet’s current service documentation notes that a hardware switch may be converted to a software switch when the target lacks equivalent hardware-switch support. Knowing this in advance lets the network team plan physical ports, VLANs and switch relationships rather than discovering them late.
Create a cleaner handover record
A well-scoped migration leaves behind more than a working appliance. It can produce a clear record of source and target models, interface mapping, major policy decisions, exceptions, converted configuration, validation checks and backup files. That information helps future administrators understand how the firewall arrived at its current state.
Control business disruption
The strongest benefit is not the conversion file itself; it is the ability to prepare the target device, predefine tests, protect a rollback path and align the work with an approved maintenance window. This matters for Uganda organisations that depend on internet banking, cloud accounting, ERP, email, remote branches, payment systems, hosted applications or operational VPN links.
The useful distinction is between configuration conversion and migration engineering.
Fortinet provides the conversion mechanisms, including FortiConverter Service, the FortiConverter Tool and supported FortiGate-to-FortiGate workflows in FortiOS. A business project still needs engineering decisions around what should move, how source interfaces map to the target, what dependencies sit outside the firewall, and how the new appliance will be validated in the actual network. FourTeck’s role is to help turn the vendor-supported conversion path into a practical Uganda deployment plan rather than treating the generated file as the end of the job.
FortiGate-to-FortiGate conversion
Fortinet documents cross-model FortiGate configuration migration, with current exceptions and conditions that should be reviewed before cutover.
Third-party firewall translation
The service supports a broad set of established firewall vendors, allowing policies and objects to be translated into FortiOS form where supported.
Manual tuning can still be required
Network overlap, unsupported external-device upgrades, new feature design and target-model differences can require manual changes after conversion.
Migration scope and technical requirements
| Service purpose | Convert and prepare an existing FortiGate or supported third-party firewall configuration for a target FortiGate, followed by review and deployment planning. |
| Supported source type | Older FortiGate configurations and supported third-party firewall platforms. Exact vendor and model support should be confirmed against the current FortiConverter documentation. |
| Target platform | FortiGate hardware or supported virtual appliance, based on selected target model and FortiOS release. |
| Primary inputs | Source configuration file; target model and version; interface mapping; network topology; VDOM state; VPN, routing and dependency information. Fortinet’s service portal guidance specifically calls for source configuration and physical interface mapping. |
| FortiGate GUI migration conditions | Current FortiOS documentation states that source and target FortiGates must be registered under the same FortiCare account, require internet connectivity to the FortiConverter server, and the target must have a valid FortiConverter licence for the GUI workflow. |
| FortiGate-to-FortiGate entitlement | Fortinet documentation describes a free opt-in licence path for eligible FortiGate-to-FortiGate configuration conversion. Eligibility and current terms should be checked for the specific devices and account. |
| Third-party migration entitlement | Paid FortiConverter Service or another suitable Fortinet migration option, based on the selected source vendor, target and service scope. |
| Converted output | Converted FortiOS configuration file. Fortinet service materials also describe summary or audit information associated with service delivery. |
| VDOM conversion | Fortinet’s current FortiGate migration guidance states that conversion between non-VDOM and VDOM mode is supported, subject to project-specific review. |
| Network overlap | Merging configuration is supported when there is no network overlap. Where overlap exists, Fortinet notes that converted files may be delivered but manual tuning is required. |
| External managed devices | Upgrades for managed software or external devices such as FortiAP, FortiToken, FortiClient EMS, FortiManager and FortiSwitch are not part of the FortiGate configuration migration itself. |
| New feature design | Limited addition of features such as SD-WAN or link aggregation may be supported in the conversion scope; broader design of features not present in the source configuration should be treated as separate engineering work. |
| Credentials and secrets | Current FortiConverter Service guidance says encrypted secrets such as VPN pre-shared keys, certificates, local users and admin passwords generally remain valid after cross-model migration when FortiOS is above 5.6, while the default admin password is reset for security. Validate sensitive settings before production use. |
| Cutover behavior | Applying or restoring a migrated configuration causes the FortiGate to restart. Backups, an approved change window, console or local access where appropriate, validation steps and a rollback path should be prepared in advance. |
The items that most strongly change the scope are the source platform, target FortiGate model, target FortiOS release and interface topology. A small branch firewall with a few policies and one VPN is a different migration from a multi-interface appliance with VDOMs, dynamic routing, site-to-site tunnels, inbound publishing, many security policies and dependencies on FortiSwitch, FortiAP, FortiManager or external authentication.
Buyers should also distinguish conversion from redesign. If the goal is simply to preserve a working architecture on newer FortiGate hardware, the migration can focus on accurate translation and validation. If the project also introduces SD-WAN, new WAN providers, new VLANs, a different addressing plan, new VPN topology, high availability, central management or major policy cleanup, those additions should be explicitly scoped so that the cutover has enough time and test coverage.
Five questions to answer before the conversion ticket or change window
What is the operational requirement?
State why the firewall is changing. Is the current appliance being replaced because of lifecycle, throughput, interface count, support status, a failed unit, branch standardisation, security requirements or a move from another vendor? This answer affects whether the project should be like-for-like or whether architecture changes need to be included. A refresh driven by capacity may also require policy and inspection review so the new platform is configured to use the capabilities for which it was selected.
What scale must be preserved or increased?
Record WAN links, expected bandwidth, user population, VLANs, policy volume, VPN peers, remote users, routed networks, public services and important business applications. The migration file may convert correctly but still be unsuitable if the target model was undersized or if a new inspection profile changes the traffic load. Capacity planning and configuration migration are linked decisions even though they are not the same task.
What must remain compatible?
List ISP handoffs, switches, access points, VLAN trunks, routing neighbours, authentication servers, DNS, DHCP, VPN peers, FortiManager, FortiAnalyzer, logging systems, certificate dependencies and any hosted service using public NAT. Fortinet explicitly excludes upgrades of several managed external products from the FortiGate conversion scope, so those dependencies need their own compatibility check rather than being assumed to move automatically.
What growth or design changes are expected?
Decide whether the new FortiGate will immediately add SD-WAN, high availability, additional WAN circuits, more branches, new segmentation, different address ranges or central management. A conversion can be more predictable when it first reproduces the known working state, after which new features are introduced in controlled stages. If the business needs those changes at cutover, they should be documented as separate design tasks rather than hidden inside a generic migration request.
What are the delivery, access and support expectations?
Confirm where the target device will be staged, who can provide administrator access, whether console access is available, what change window is approved, who can validate business applications, how rollback will be performed and what documentation is required at handover. For a Uganda project, also include site location, remote or onsite coordination expectations and whether multiple branches must be scheduled around the same head-office change.
Migration scenarios where preparation has direct operational value
Head-office FortiGate hardware refresh
A company has an older FortiGate that already carries internet breakout, site-to-site VPNs, server publishing, VLAN segmentation and security policies. The business wants a newer model without recreating the whole rule base. This is a strong FortiGate-to-FortiGate migration case, but the team still needs to map physical interfaces, check FortiOS compatibility, verify unsupported external-device dependencies and prepare rollback. If port layouts differ, the target wiring plan must be agreed before the converted configuration is applied.
Cross-model conversion may alter switch constructs or interface references. Validate WAN, trunk and management ports against the target hardware before cutover.
Multi-branch organisation standardising on FortiGate after using a supported third-party firewall platform.
Third-party firewall replacement
The source firewall may contain years of network objects, access rules, NAT definitions and VPN relationships. FortiConverter can translate supported configuration constructs into FortiOS syntax, giving the new FortiGate a structured starting point. The important buyer task is to identify differences in feature behaviour instead of assuming every vendor concept has a perfect one-to-one equivalent. Interface mapping, route logic, VPN parameters, object cleanup and security-profile design deserve explicit review.
Branch consolidation and standard template rollout
A business may have several sites with similar but not identical policies. Migration becomes an opportunity to decide which settings are site-specific and which should become a common FortiGate baseline. A converted configuration can preserve local requirements while the project also documents standard naming, admin access, logging and backup expectations. The main caution is network overlap: if branches reuse the same subnets or the target configuration must merge with an existing template, manual tuning can be required.
Shared templates should not erase legitimate site differences. Record WAN addressing, local subnets, DHCP, VPN peer identity and any branch-specific published service before standardising.
Replace a failing or constrained firewall with minimum avoidable downtime and a credible rollback path.
Business-continuity replacement
When a firewall replacement is urgent, the temptation is to move quickly and test later. A better approach is to preserve a source backup, prepare the target configuration, list critical services, pre-stage cables and management access, and identify the exact point at which rollback will occur if validation fails. The migration service is valuable because it can reduce rebuild effort, but the continuity benefit comes from pairing conversion with disciplined change control.
Interface mapping is the bridge between a valid file and a working network
The source firewall knows interfaces by names and roles that may not exist on the target. A WAN circuit might currently terminate on a port that becomes a different numbered interface on the new FortiGate. VLANs may sit on a physical interface, an aggregate, a software switch or a hardware switch. A DMZ may move to a different port group. Management may need to remain reachable on a dedicated interface. If those relationships are wrong, a configuration can be syntactically valid and still disconnect the site.
That is why Fortinet asks for physical interface mapping when a configuration is submitted through the FortiConverter Service workflow. The mapping should describe not only which source interface corresponds to which target interface, but also what is connected: ISP router, core switch, access switch, server segment, HA heartbeat, out-of-band management or another network device. For trunk links, record the VLANs expected on that interface. For aggregate links, confirm the target supports the required design and that the connected switch is configured consistently.
The buyer outcome is simple: fewer surprises during cutover. FourTeck can use the interface map to help build a cable plan, validation list and staging checklist. This is especially useful when the new FortiGate has a different physical layout or when the migration introduces fibre, higher-speed ports, new transceivers or different switch connectivity. Those hardware details are outside the configuration file but directly affect whether the converted settings can operate.
Know the conversion boundaries before approving the maintenance window
A migration tool is most useful when everyone understands what it is and is not responsible for. Current Fortinet guidance supports FortiGate-to-FortiGate conversion broadly, but it also lists clear exceptions. Managed external devices are not automatically upgraded as part of the FortiGate migration. Configuration merges involving network overlap can need manual tuning. New feature creation is limited compared with a dedicated redesign. These boundaries are not shortcomings; they are planning signals that tell the buyer where engineering effort is still required.
Cutover and rollback discipline protects the business more than speed alone
Applying a migrated configuration can restart the target FortiGate, so the change must be treated as a controlled service interruption unless the surrounding architecture provides another continuity method. Before the window, preserve the source configuration, keep a clean target backup, confirm administrator credentials, verify local or console access where appropriate and make sure someone is available to test the applications that matter to the business. A firewall can pass basic internet traffic while still breaking a branch tunnel, inbound service or route to a critical server.
Rollback should have a trigger, not just a backup file. Decide how long the team will troubleshoot before returning to the previous device or configuration, and define which failures require immediate reversal. If the source appliance is being physically removed, label cables before the change so they can be restored quickly. If IP addressing or upstream equipment is changing at the same time, record those changes separately because rollback may require reversing them too.
Buyer decision checklist
- Source and target configuration backups stored securely.
- Target FortiOS and migration eligibility confirmed.
- Interface and cable map checked against the physical appliance.
- Critical VPN, routing, NAT and business application tests written in advance.
- Administrator and emergency access method confirmed.
- Rollback trigger, responsible person and restoration steps agreed.
- Post-change configuration backup and handover documentation included.
What buyers should check before purchase or migration approval
One additional commercial risk is treating migration as a fixed-price task before the configuration has been characterised. Policy count alone is not enough: a smaller firewall can be complicated by many VPNs, overlapping networks or third-party dependencies, while a larger appliance may have a clean and standard design. A useful quote therefore asks for the variables above and states which work is included, which items depend on Fortinet service entitlement, and which architecture changes would be separate.
Plan the migration around the actual firewall, entitlement and site requirement
FourTeck supports Uganda organisations that need assistance scoping a FortiGate migration, selecting or confirming the target appliance, preparing migration inputs and obtaining a project-specific quotation. Availability of hardware, service entitlement and engineering time can vary, so the practical starting point is to share the source and target details rather than assume a standard package. For Kampala projects, the scope may include a single head-office replacement, a branch rollout, a staged migration or a broader firewall refresh that needs coordination with switches, ISPs and application owners.
FourTeck can help review the configuration variables, identify information that FortiConverter requires, clarify where manual tuning may be needed, and coordinate delivery or deployment planning around the customer’s approved change window. Warranty guidance for any associated FortiGate hardware should be based on the selected product and current commercial terms, while migration service entitlement should be confirmed against the Fortinet account and target device. For project or quantity requirements, include the number of sites and whether the configurations are common templates or individually customised.
One migration plan can support head office and distributed sites
FourTeck can coordinate quotation and migration planning for organisations operating in Kampala, Entebbe, Jinja, Mbarara and Gulu. The technical work does not change because of the city name, but logistics and validation responsibilities can change when the firewall protects a remote branch rather than the main office. A multi-site request should therefore identify which location hosts the source firewall, which site receives the target appliance, whether branch VPNs terminate on the device being replaced, and who can verify connectivity at each location after cutover. This keeps the location discussion practical and prevents separate city-by-city assumptions from replacing the actual network design.
Regional projects need a common migration method and local validation ownership
For organisations that operate beyond Uganda, the same migration framework can be used to coordinate firewall refresh work across Kenya and selected East Africa markets, provided each site’s configuration and logistics are reviewed separately. A regional project benefits from a standard information pack: source and target model, firmware, interface map, policy and VPN scope, branch addressing, test plan and rollback owner. Standardisation can reduce project variation, but it should not hide site-specific WAN or application requirements.
FourTeck also supports broader procurement conversations through its Africa, UAE and Kuwait web presence where relevant to multinational customers. This should not be interpreted as a guarantee of local stock, a local branch in every market or identical service terms. Regional delivery, licensing, commercial conditions and warranty handling depend on the actual project. Uganda buyers with a cross-border rollout can start with the local scope and identify which additional sites require the same target standard.
Useful next steps for a FortiGate refresh project
Practical assistance around the migration decision
FortiGate migration questions for Uganda buyers
Can an old FortiGate configuration be moved to a newer FortiGate model?
Yes, Fortinet documents FortiGate-to-FortiGate configuration migration through FortiConverter, including cross-model conversion. The target model, FortiOS version, interfaces and migration eligibility still need review. A converted file should be validated before production because physical port layouts, switch constructs, VDOM use and external dependencies can differ between the old and new appliances.
Can FortiConverter migrate from a third-party firewall to FortiGate?
Yes, Fortinet lists support for a broad range of established firewall vendors. Exact source-model support and the treatment of specific features should be checked against the current FortiConverter documentation. Third-party migration is also different commercially from eligible FortiGate-to-FortiGate conversion, so the source vendor and target FortiGate should be stated in the quote request.
What information is needed before a migration can be scoped?
Start with the source vendor and model, source firmware, source configuration backup, target FortiGate model, intended FortiOS version and interface mapping. Add VDOM status, WAN circuits, VLANs, VPNs, routing, managed Fortinet devices, authentication dependencies, public services and the desired change window. A network diagram is very helpful when interface names alone do not explain the topology.
Does FortiGate-to-FortiGate migration require a FortiConverter licence?
For the FortiOS GUI migration workflow, current Fortinet documentation says the target FortiGate needs a valid FortiConverter licence and both devices must meet the stated account and connectivity conditions. Fortinet also documents a free opt-in licence path for eligible FortiGate-to-FortiGate conversion. Confirm the current entitlement for the exact target device before scheduling the work.
Will every setting migrate automatically?
No. Fortinet lists exceptions and situations that need manual attention. Managed external-device upgrades are outside the FortiGate conversion, network overlap can require tuning, and designing major new features that were not present in the source is not the same as configuration conversion. Treat the converted result as an engineered starting point that still needs review against the target network.
What happens to VPN keys, certificates and administrator credentials?
Current FortiConverter Service guidance says encrypted secret data such as VPN pre-shared keys, certificates, local users and admin passwords generally remain valid after cross-model migration when FortiOS is above 5.6, while the default admin account password is reset for security. Sensitive authentication should still be tested and documented because legacy versions and special cases can behave differently.
How much downtime should we expect?
There is no universal downtime figure. Applying or restoring the migrated configuration restarts the FortiGate, and the overall interruption also depends on cabling, ISP changes, routing convergence, VPN establishment and validation. A good project minimises avoidable delay by staging the target, labelling cables, preparing tests and agreeing a rollback trigger before the maintenance window starts.
Can we add SD-WAN or redesign the network during migration?
It is possible to combine migration with design changes, but they should be explicitly scoped. Fortinet notes limited support for adding features such as SD-WAN or link aggregation during conversion, while broader new-feature design can require separate assistance. For lower risk, many teams first reproduce the required working state and then introduce larger architecture changes in controlled stages.
How do I request a FortiGate migration quote in Uganda?
Send FourTeck the source firewall model and firmware, target FortiGate model, intended FortiOS release, site location, interface mapping, VPN and routing scope, approximate policy complexity, managed Fortinet dependencies and preferred change window. If the target is not selected yet, include internet bandwidth, users, VPN count and growth expectations so hardware selection can be reviewed before migration effort is priced.
Prepare the migration scope before the firewall enters the change window
A useful request gives the technical team enough information to separate conversion, hardware selection, licensing, deployment and redesign. Share the source and target models, FortiOS versions, interface map, VDOM status, important VPNs, routing dependencies, managed Fortinet devices, site location and expected cutover date. FourTeck can then respond with a practical scope and quotation path for the Uganda project.
Technical reference: Fortinet FortiConverter Service and current FortiOS migration documentation. Exact support, entitlement and behaviour remain configuration dependent.