Planning before purchasing
A new server, fast computers and a high-performance internet connection can fill a shopping list. They do not, on their own, create a well-designed IT infrastructure.
For me, planning starts with different questions. Which tasks must work reliably? Which data must never be lost? Who looks after the systems when something fails? And could someone else take over without having to decipher the entire environment first?
Building a new infrastructure is an opportunity to settle these questions properly. It should not be wasted by moving old problems onto new equipment.
Rethinking IT does not mean using as much technology as possible. It means using the right technology in a way that supports work over the long term.
Understand what is needed first
Before ordering equipment or signing a cloud contract, establish the actual requirements.
Which applications are used? Where is their data stored? Who works in the office and who remotely? Which devices need network access? Which services depend on an external provider?
In its small-business guide published on 26 February 2024, the US National Institute of Standards and Technology recommends starting with an inventory of hardware, software, systems and services. Assessing the consequences of their failure is equally important. [1]
For a small trade business, this might mean prioritising job management, email, customer documents and mobile devices. A development office might need large project files, computing capacity and version control. The same shopping list would hardly suit both.
Review the existing environment critically too. An application should not be retained merely because it has been running for years. Another solution may serve its purpose better, or an unnecessarily complicated process may be simplified.
The outcome of this assessment should explain what the new infrastructure must achieve. Only then should component selection begin.
Availability needs specific objectives
“The IT must not fail” is understandable, but not very useful for planning. Sound decisions need more precise requirements.
Two terms help: RTO is the recovery time objective. RPO is the recovery point objective — the point in time to which data must be restored, and therefore how much recent data loss can be tolerated. NIST explains this distinction in its 2010 contingency planning guide. [2]
As a simplified example, a business might require its job management system to be usable again within four hours, with no more than the last hour's changes lost.
An evening backup alone would not meet that requirement. Nor would a complete backup if restoring it and restarting the application took an entire day.
Those times are illustrations, not general recommendations. They show why downtime and data loss need separate planning.
For me, this also requires a recovery order: central sign-in, job management or file access first? Leaving those decisions until an incident means postponing an essential part of the planning.
Your own servers, cloud services or both?
The operating model should not become a matter of faith.
For each important application, I would assess where it can sensibly run under the actual circumstances. Technical needs, available expertise, internet dependency, costs and data handling all matter.
The BSI's “OPS.2.2 Cloud-Nutzung”, Edition 2023, addresses provider dependency, an orderly exit from cloud services and portability. A potential later change of provider therefore belongs in the initial selection process. [3]
Before outsourcing, I would ask: in what format can I retrieve my data? What assistance is available when switching? What happens to accounts, permissions and integrations? Which responsibilities explicitly remain with the customer?
Running systems yourself raises different questions. Who installs security updates, checks backups and arranges replacements? Who covers holidays or illness?
A combination can make sense: some applications as external services, others on your own infrastructure. It should have a clear purpose. I would not add a connection between environments simply to solve a problem that a simpler design could have avoided.
The best solution is not necessarily entirely local or entirely in the cloud. It is the one whose operation and risks can be managed.
A network needs boundaries
A network should not merely connect devices. It should also define which connections are prohibited.
Australian cybersecurity guidance checked on 9 October 2026 explains how separate areas and controlled connections can make an attack harder to spread. Dividing the network is not enough: access rules must be enforced effectively. [4]
For a manageable environment, one possible structure would be:
Workstations: access to the applications and shared data they need.
Servers and central services: only connections required by each service.
Infrastructure management: access only for authorised administrators and designated management devices.
Printers, cameras and other network devices: no blanket access to every workstation and server.
Guest network: internet access without access to internal systems.
This is a planning example, not a finished ruleset. The appropriate separation depends on the environment.
VLANs, logically separate network areas, are one technical option. A VLAN arrangement alone does not determine which communication between those areas is permitted. Suitable filtering and access rules are still required. [4]
A new design is a good opportunity to document the necessary connections. A printer needs to print; that does not mean it should communicate without restriction with every other device.
Access rights matter as much as network boundaries
A device or user should not be trusted solely because it is inside your network. NIST's “Zero Trust Architecture”, published in August 2020, describes this principle: identity and authorisation should govern access, not simply internal network membership. [5]
In practice, this includes individual accounts, task-related permissions and an orderly withdrawal of access no longer required. NIST's 2024 guide also recommends multi-factor authentication for accounts that support it. [1]
For me, a new system is not properly configured if everyone can work but nobody can explain why particular people have extensive privileges.
Computing power is not the same as resilience
A powerful computer can run several virtual servers, allowing applications to be managed separately.
That separation does not remove every shared dependency. If all virtual systems run on a single physical computer and it fails, their services become unavailable too unless an appropriate replacement arrangement exists.
NIST's January 2011 virtualisation guide explains the importance of the hypervisor, the software managing virtual machines. If that layer is compromised, several systems running on it can be at risk together. [6]
I would therefore compare more than memory, processor cores and storage. Which services share a single point of failure? What replacement options exist? How long does recovery actually take?
Two servers are not an independent infrastructure if both rely on the same sole storage system or the same unprotected power supply.
Power and location belong in the design
The installation location deserves attention too. I would consider physical access, heat removal, protection against water and the power supply.
An uninterruptible power supply can bridge limited outages or allow an orderly shutdown. Connected equipment, required runtime and behaviour during an outage must be coordinated. Emergency power and preventative measures also feature in NIST's 2010 contingency planning guide. [2]
I would label cables and connections clearly during installation. Having to identify which connection belongs to which device during an incident wastes time on something that could have been settled beforehand.
A backup is convincing only after a restore test
A green tick in backup software is welcome. It does not establish whether the application you need can run again from that backup.
The BSI's “CON.3 Datensicherungskonzept” explicitly identifies missing restore tests as a risk. Backups and their practical usability need to be considered together. The directly verifiable official source for this check was Edition 2022. [7]
Before accepting a new environment, I would require at least one real restoration in a suitable test environment. Opening a few files would not be enough: databases, permissions, configurations and required keys must be included.
A snapshot stored only on the same storage system as production cannot help if that entire system is lost. Nor does a second disk automatically constitute a complete backup strategy.
In its StopRansomware Guide, researched on 9 October 2026, CISA recommends additional offline, encrypted backups of critical data and regular tests of their availability and integrity. [8]
For me, a usable backup strategy must deliver three things: the required data exists, it is protected against relevant loss scenarios and restoration works within the agreed objectives.
That must remain true even when the usual administrator is unavailable.
Plan ongoing operations from the start
An infrastructure is not finished once installation ends. That is when it needs ongoing care.
The BSI's “OPS.1.1.1 Allgemeiner IT-Betrieb”, Edition 2023, covers administration, documentation and IT monitoring, among other responsibilities. Secure operation is a task in its own right, not an occasional extra. [9]
At handover, I would document who assesses updates, handles faults and can make decisions during a security incident. Maintenance windows and cover arrangements belong there too.
Monitoring should tell us more than whether a server responds. Failed backups, diminishing free space, expiring certificates and unusual sign-ins also matter.
A warning has a purpose only if it reaches someone able to assess and act on it. An overflowing alert list without assigned responsibility would not be adequate monitoring.
Documentation should describe essential dependencies: which application needs which database, where configurations are backed up and how a replacement device is introduced.
The environment should be understandable to more than the person who built it.
Data protection is a planning task
When personal data is processed, technical and organisational safeguards must match the risk. The European Data Protection Board makes this clear in its small-business guidance checked on 9 October 2026. [10]
For infrastructure planning, establish which data is stored where, who may access it and how it is protected against unauthorised use or loss.
If a provider acts as a data processor, its duties and obligations must be defined appropriately. The European Commission explains that a contract or another binding legal act is generally required. [11]
I would not leave these questions until after go-live. A generic sentence in a privacy notice cannot retrospectively justify an already established data flow.
The same applies to new AI applications. For an initial test, I would use cleaned sample data rather than immediately providing access to the entire customer archive. Further data access should follow from a specific task.
Look beyond the purchase price
I would prepare a multi-year cost estimate, including equipment and setup alongside licences, maintenance, backups, energy, training and eventual replacement.
A simple calculation shows why ongoing consumption matters: an additional constant 100 watts amounts to 876 kilowatt-hours over a 365-day year. This is not a measurement of a particular installation and does not include additional cooling or other equipment.
I would account for my own time too. A low-priced solution is not automatically inexpensive if it requires constant manual work.
Hardware selection should also address the intended service life and support from manufacturers and providers. Before purchasing, I want to understand the outlook for security updates, spare parts and compatible expansion.
There is no need to pay immediately for every conceivable expansion. A credible upgrade path can be more sensible than buying capacity that remains unused.
The transition needs a way back
I would move to the new infrastructure in stages.
Start with a manageable group of devices or a limited application. Users test their real tasks: signing in, opening documents, editing data, printing and, where required, remote access.
Then verify the technical requirements. Do backup and restoration work? Are permissions correct? Are faults detected? Have the agreed performance objectives been met?
Before the switchover, define stop criteria and rollback procedures. Which problems would halt the migration? Which data has already changed, and how would those changes be handled when going back?
Keeping the old server in the room does not, by itself, provide a rollback plan.
Acceptance should include handing over to the people who work with and maintain the environment. They need understandable instructions, contact points and a way to report faults or uncertainties.
I would retire old systems only after the essential tasks demonstrably work.
My conclusion: better infrastructure need not be bigger
To me, “rethinking IT” is not a competition to own the most devices, use the newest terminology or build the most elaborate architecture.
What convinces me is an environment whose design can be explained. Necessary applications work. Access is limited. Data can be restored. Costs and responsibilities are known. Changes can be made without turning the entire business into an experiment each time.
That takes planning first, not necessarily more hardware.
I would prefer a well-reasoned, manageable solution to a technically impressive system that nobody can maintain reliably.
Good IT is not just recognisable because it works today. It can still be understood, maintained and restored when needed tomorrow.
Scope and research
Research updated on 9 October 2026. The examples are general planning aids, not a complete security, data protection or operating design for a particular environment. Suitable measures depend on the circumstances. This article does not replace individual technical or legal advice.
Sources and further reading
Sources checked on 9 October 2026. Some BSI and CISA pages could not be opened directly; the cited recommendations were checked through the original-source search index. For CON.3, the verifiable Edition 2022 replaces the draft reference to Edition 2023. Older guidance supports foundational concepts here, not current product-specific installation instructions.
[1] NIST: „Cybersecurity Framework 2.0: Small Business Quick-Start Guide“
Read source ↗
[2] NIST: „Contingency Planning Guide for Federal Information Systems“, SP 800-34 Revision 1
Read source ↗
[3] BSI: „OPS.2.2 Cloud-Nutzung“
Read source ↗
[4] Australian Signals Directorate / Australian Cyber Security Centre: „Implementing network segmentation and segregation“
Read source ↗
[5] NIST: „Zero Trust Architecture“, SP 800-207
Read source ↗
[6] NIST: „Guide to Security for Full Virtualization Technologies“, SP 800-125
Read source ↗
[7] BSI: CON.3 Datensicherungskonzept, Edition 2022 (directly verifiable source for restore testing).
Read source ↗
[8] CISA und Partnerbehörden: „#StopRansomware Guide“
Read source ↗
[9] BSI: „OPS.1.1.1 Allgemeiner IT-Betrieb“
Read source ↗
[10] Europäischer Datenschutzausschuss: „Secure personal data“
Read source ↗
[11] Europäische Kommission: „Application of the GDPR“
Read source ↗