A switch purchase can look simple when it is reduced to the number of available ports. In practice, the attached devices may require different power levels, the uplinks may carry several busy services and the management design may depend on a specific combination of platforms and software releases.
FortiSwitch deployment planning should bring those requirements together before equipment is ordered. The exact model matters, including its variant, supported interfaces and power characteristics. A family name or a photograph of the front panel is not enough to establish suitability.
For an office, school, warehouse or hospitality site, the useful question is whether the complete installation will support the intended work and remain manageable. This guide provides a practical review process without assuming a universal power budget, uplink capacity or management feature across FortiSwitch models.
Build the port schedule from real endpoints
Start with an endpoint register for each wiring cabinet. Include workstations, access points, phones, cameras, printers and any specialist equipment that will connect. Record the physical location, responsible owner, expected network role and whether the device needs power from the switch.
Separate installed devices from planned growth. A spare-port allowance is useful only when it reflects plausible additions. An office expecting more access points has a different requirement from one expecting only additional printers, because port speed and power demand may differ.
Identify devices that cannot tolerate a simple working-hours interruption. An access-control controller or operational terminal may need a coordinated maintenance arrangement even if its bandwidth use is modest. The endpoint register should reveal these dependencies before a cabinet change is scheduled.
Use the register to produce a port schedule with clear labels. A technician should be able to trace a port to its intended endpoint and network role without relying on someone else’s memory. This also makes later fault investigation and changes more reliable.
Calculate power as a shared resource
For every powered endpoint, obtain the relevant manufacturer’s power requirements for the actual device and operating mode. Do not assume that two access points or cameras need the same allocation because they belong to the same general category.
Check both the power available at an individual port and the total power available from the selected switch configuration. A device can satisfy the per-port requirement while the combined endpoint demand exceeds the switch’s overall capacity. Conversely, a large total budget does not prove that every port can supply the requirement of a particular endpoint.
Include planned growth and any operating conditions that change demand. Some devices may behave differently when additional functions are enabled. Have the design identify the basis of each power figure rather than mixing maximum ratings, typical observations and assumptions without explanation.
Fortinet’s FortiSwitchOS 7.4.7 documentation describes configurable maximum power modes on PoE ports. That software capability is not a substitute for checking the exact hardware’s port limits and overall budget. Validate the supported configuration and model specifications together before approving the design.
Examine what happens after a power interruption
A switch that powers all endpoints during normal operation still needs a recovery assessment. Consider the effect of a cabinet power loss and the subsequent restart of connected devices. The business concern is when critical services return and whether the sequence creates unexpected problems.
If the design includes backup power, calculate the requirement for the complete cabinet equipment rather than the switch alone. Include the connected powered load and the other devices needed for the service to function. A functioning access point offers limited value if its upstream network or required application is unavailable.
Agree which endpoints are operationally critical. This helps the team assess any supported power prioritisation options and decide how to respond if available power is constrained. Verify the actual model and release behaviour rather than assuming that every switch offers the same controls.
Rehearse recovery in an approved test or maintenance window. Record endpoint restart behaviour, network availability and any devices requiring manual attention. The resulting evidence can guide support instructions and identify equipment that needs special handling.
Size uplinks around traffic paths
List where traffic goes. Staff internet access, local file transfers, camera streams and interdepartmental applications may use different paths through the network. A busy access layer does not automatically produce the same load on every uplink, but the design should explain which services share each path.
Consider simultaneous activity. A warehouse upload process and a camera recording flow may overlap even if each looks modest in isolation. Use observed requirements or clearly stated planning assumptions to evaluate capacity instead of relying only on the sum of access-port speeds.
Check the interfaces and media at both ends. Supported port speeds, optics, cable type, distance and the neighbouring device all matter. A compatible connector shape does not independently prove that the selected components form a supported link.
Where resilience is required, describe the failure scenario the uplink design addresses. Multiple cables do not by themselves establish a safe redundant topology. The implementation team must validate the supported design, loop prevention and recovery behaviour for the actual platforms and releases.
Decide the management model before installation
Determine whether the switch will be managed through a FortiGate-supported FortiLink design or through another supported operating arrangement. That decision affects responsibilities, compatibility checks, recovery procedures and the information the support team needs.
Fortinet provides a FortiLink guide for managed FortiSwitch deployments, including a FortiSwitch management section for version 7.4.8. Use the documentation applicable to your selected releases and consult the relevant compatibility information. Do not infer support from the fact that both devices carry the same vendor name.
Map the management path and account ownership. Identify who can make port changes, who approves network-role assignments and how the team accesses the environment during a fault. A central management approach still needs a plan for loss of the normal management route.
If the installation spans several cabinets or branches, agree a consistent naming scheme and documentation standard. Maxicon’s network infrastructure services can help frame a discussion about physical connectivity and management responsibilities as one deployment requirement.
Validate network roles at the access port
Each port should have an intended role that corresponds to an approved endpoint or use case. Staff workstations, guest access points and building systems may require different network treatment. Capture those distinctions in the design before technicians begin patching cables.
Review the complete path for each role. The switch configuration, upstream interfaces and relevant gateway policies must agree about where the traffic belongs and what it may reach. A correct port label does not prove that the traffic remains separated elsewhere in the network.
Include unexpected-device handling in the operational discussion. Decide what staff should do when an unknown device is connected or when an endpoint is moved to another port. The supported technical controls should implement an explicit organisational decision rather than an assumption that physical access is always controlled.
Use test endpoints to verify the intended result. Confirm access to required services and check relevant boundaries. Record the port, endpoint, network role and observed outcome so the acceptance evidence can be traced back to the design.
Prepare the physical installation properly
Survey the cabinet before the equipment arrives. Check rack space, ventilation, power connections, cable organisation and access for maintenance. A model that meets the logical network requirements can still be unsuitable for the physical location or the available power arrangement.
Inspect and identify existing cabling. An intermittent link may originate in a patch lead, termination or cable run rather than the new switch. Establish the condition of the infrastructure so deployment testing does not become an uncontrolled investigation of old faults.
Prepare labels and a patching plan before cutover. Photograph or document the existing arrangement where appropriate, while avoiding unnecessary exposure of sensitive information. The recovery plan should allow the team to identify the previous connections if the change must be reversed.
Coordinate with the people who own connected systems. Camera, telephony and facilities teams may need to participate in acceptance. Their equipment can appear connected from a network perspective while the actual service still needs application-level verification.
Accept the installation against concrete tests
Use a test sheet based on the endpoint and port schedules. Confirm link establishment, intended role, required power delivery and the business function of representative devices. Include endpoints with distinctive requirements rather than testing only an ordinary laptop.
Observe uplinks while relevant workloads operate. The aim is to establish that the design supports the intended activity under the agreed conditions. Avoid translating a short test into an unsupported promise about every possible future workload.
Test management access and the support workflow. The responsible team should be able to identify a port, obtain relevant status information and follow the agreed change process. Documentation should include device identities, versions, connection maps and the approved configuration record.
Record unresolved items explicitly. A temporary patch lead, deferred endpoint or untested recovery scenario should have an owner and completion date. The site should not be declared fully accepted while important limitations remain hidden in an engineer’s informal notes.
Plan for additions after handover
Require new endpoint requests to include power and connectivity needs. This keeps the original capacity assessment meaningful as the site changes. A spare port is an opportunity for expansion, not automatic permission to attach any device without review.
Revisit the power and uplink calculations when substantial equipment is added. Keep the port schedule current and remove obsolete assignments. These small maintenance habits prevent the next expansion from beginning with an unreliable inventory.
To discuss a FortiSwitch deployment, contact Maxicon with the endpoint list, cabinet layout, proposed switch variants and management preference. Those inputs make it possible to evaluate the installation as a complete service rather than a port-count exercise.
Frequently asked questions
Is the number of PoE ports enough to size a switch?
No. Check individual port capability, the total available power budget and the actual endpoint requirements. Include plausible growth and the selected hardware configuration. Port count alone does not establish how much power can be supplied simultaneously.
Can any FortiSwitch be managed by any FortiGate?
Do not assume universal compatibility. Verify the exact models, software releases and supported management topology using the relevant Fortinet documentation. Record the approved combination so future upgrades can be reviewed against it.
Should every access port have the same configuration?
Only where the intended endpoint roles justify it. Different devices may need different network treatment or operational controls. Use a documented port schedule and validate the complete traffic path for each role.
Why test a power restart during acceptance?
It reveals how the switch and attached endpoints return to service after an interruption. Some devices may require more time or manual attention. Conduct the exercise safely and record the actual recovery behaviour for the support team.
What information should be handed to support?
Provide the device and version inventory, port schedule, uplink map, power assumptions, management route, approved configuration record and acceptance results. Include unresolved exceptions and ownership so future work begins from a reliable view of the installation.
Related technology support
For an additional service perspective related to this guide, explore Trubyte’s Fortinet and managed security services.
Discuss your requirements with Maxicon
Tell us about your business, current environment and the support you need.
