A data center has more than one lifetime

At the end of its fourth year, a server can disappear from an accounting model while remaining bolted into a rack.

Google’s first-party carbon-footprint methodology spreads the emissions associated with manufacturing data-center equipment across four years, a period chosen to match its financial accounting. Google notes that equipment often remains in service longer. It assigns the embodied emissions of data-center buildings across 20 years.

Nothing physical happens when either accounting period ends.

The server does not stop working. The concrete does not dissolve. The cooling equipment does not forget how to move heat. A reporting convention has reached its boundary; the infrastructure has not necessarily reached the end of its useful life.

This is one reason the environmental impact of a data center is difficult to compress into a dashboard.

The facility contains layers that age at different speeds. A building may house several generations of computing equipment. Power and cooling systems can be repaired, expanded, or replaced on their own schedules. Servers contain components with different failure rates and upgrade paths. Accelerators may become commercially unattractive while remaining technically functional.

Then there is the electricity meter, counting a different kind of impact every hour the site operates.

Power Usage Effectiveness and Water Usage Effectiveness begin their most useful work during operation. They show what the facility requires while computing equipment is running.

The physical footprint began much earlier.

It started with mined materials, chip fabrication, steel, concrete, cooling machinery, electrical equipment, manufacturing, and transport. It continues through maintenance and replacement. It ends, if the boundary is drawn that far, with reuse, recycling, material recovery, or disposal.

A data center therefore has no single lifetime.

It has several overlapping ones, and the environmental result depends partly on which clock we decide to watch.

The footprint begins before the first watt

Life-cycle assessment follows a product or system beyond one stage of use.

The ISO 14040 standard, used with ISO 14044, establishes principles for defining the goal, scope, inventory, impact assessment, interpretation, limitations, and review of an LCA. The first task is deciding what is being assessed and where its boundary begins and ends.

For a data center, that becomes complicated quickly.

Does the assessment cover the building and foundations? Electrical connection? Backup power? Cooling equipment? Servers and storage? Processors? Software? Electricity generation? Replacement hardware? Transport? End-of-life treatment?

Two studies can both describe a “data-center lifecycle” while including different combinations of those things.

A 2025 peer-reviewed Nature study led by Microsoft researchers attempted an unusually broad assessment of data-center cooling. It followed four cooling approaches across software, processors, servers, cooling infrastructure, the building, electricity supply, manufacturing, operation, and end of life. Under its modeled assumptions, advanced liquid-cooling approaches reduced lifetime energy, greenhouse-gas emissions, and blue-water consumption compared with the air-cooling baseline. The result belongs to those systems, assumptions, and electricity sources, not every site or workload.

The significance lies partly in what the researchers had to count.

A cold plate is not merely a device that may reduce electricity or water after installation. It has to be manufactured. It contains materials. Pumps, pipes, heat exchangers, and controls have supply chains. Changing the cooling architecture can reduce one operating burden while introducing another embodied one.

Google applied a similarly broad boundary to five generations of its AI accelerators in a first-party 2025 preprint. The analysis included data-center construction, server and accelerator manufacturing, transport, electricity used during AI development and serving, and hardware retirement.

For one TPU v5e machine configuration, it estimated around 2,277 kg of carbon-dioxide-equivalent emissions from manufacturing and another 471 kg from transport. These are not generic figures for a GPU server. They belong to Google’s hardware, supply chain, assumptions, and method. Their usefulness is in making manufacturing visible, not in creating an industry average.

Operational metrics cannot see these impacts because they were designed for another job.

PUE can show whether less electricity is being lost in cooling and power systems. It cannot show whether a new server required more manufacturing impact than the one it replaced. WUE can track water intensity during operation. It cannot describe the water and chemicals used in semiconductor production.

That distinction is central to what data-center efficiency metrics measure and leave out.

An operational improvement can be real.

It can also be one side of an exchange.

The building and hardware live on different clocks

A data center is often described as one facility, but its components do not reach obsolescence together.

The building and site infrastructure may remain useful through several technology cycles. Electrical distribution, cooling equipment, networking, racks, servers, storage, memory, and accelerators all have different repair and replacement schedules.

Accounting life, modeled life, warranty period, economic life, and physical life are not the same.

A component can remain functional after it has been fully depreciated. It can remain repairable after its original warranty expires. It can also become economically obsolete before it fails because newer hardware completes more work with the same electricity, occupies less space, or supports workloads the older system cannot run.

The environmental question is therefore harder than “How long can this equipment last?”

It is: when does the operating advantage of replacement justify manufacturing another machine?

The answer changes with the workload.

Research from the University of California, San Diego, examined whether older processors could remain useful rather than being removed on a fixed refresh schedule. Newer CPUs performed better overall, but the size of the advantage varied by workload. For some tasks, retaining older equipment could remain practical and avoid the embodied emissions of premature replacement. The study makes the case for workload-aware replacement.

Electricity changes the calculation too. In a carbon-intensive power system, replacing inefficient equipment may repay its manufacturing impact comparatively quickly through lower operating energy. Where electricity is already low-carbon, manufacturing can represent a larger share of lifetime emissions and the case for keeping functional equipment may grow.

Utilization matters. An older server operating near capacity may complete more useful work per unit of embodied impact than a new server bought speculatively and left mostly idle. Conversely, newer hardware can sometimes consolidate the work of several old machines.

There is no responsible universal refresh interval.

“Newer is more efficient” may be true at the level of performance per watt. “Keeping equipment longer avoids manufacturing” is true at the level of embodied impact. Neither decides the replacement question by itself.

Google’s TPU preprint captures the tension. Newer generations in its study carried higher embodied emissions per accelerator, partly because they contained more hardware and memory, while delivering much better carbon efficiency per unit of computation.

The newer device was not impact-free.

It performed enough additional work to change the result.

Reuse, recycling, and retirement are different outcomes

Eventually, hardware leaves its original role.

What happens next is often compressed into one reassuring word: circularity.

In practice, retirement has several possible endings.

A whole server may continue serving a less demanding workload. Components such as memory, drives, power supplies, and fans may become spares. Equipment may be sold or transferred. Materials may be recovered through recycling. Some parts may have no viable route beyond disposal.

Those outcomes preserve different amounts of value.

Reusing a functioning component retains the materials, manufacturing work, and technical function already embodied in it. Recycling can recover metals and other materials, but the energy and processing that turned them into a working server have largely been lost.

Research on embodied carbon in cloud platforms therefore argues that extending equipment life and reusing components can avoid more manufacturing emissions than relying on material recycling alone. The best route still depends on efficiency, condition, security, available second uses, and the impact of keeping the equipment in service.

Large operators are building physical systems to manage this process. Microsoft reported a combined 90.9% reuse-and-recycling rate for servers and components in 2024 and said more than 3.2 million components were reused through internal and external channels. This is first-party company reporting. Microsoft describes its Circular Centers and accounting here.

The combined percentage is useful as a waste-diversion measure. It does not reveal, by itself, how much equipment was reused intact, how much became spare parts, and how much was reduced to material.

That distinction matters because recycling one kilogram of server hardware is not equivalent to keeping one kilogram of functioning hardware in use.

Google’s AI hardware analysis took a similarly cautious approach. Its model estimated that cascaded use and material recovery could offset a small portion of embodied emissions, but the authors did not take that credit in the main result because the outcome depends on the hardware’s actual second life and treatment route.

A recycling target describes an intended process.

A lifecycle result depends on what happens to the equipment.

A lifecycle assessment is still a model

Following a data center from raw materials to retirement does not produce one indisputable environmental truth.

Life-cycle assessment is a structured model built from a purpose, functional unit, boundary, datasets, allocation choices, expected lifetimes, operating assumptions, and impact methods.

Change those assumptions and the result can change.

A facility assessed over 20 years spreads its construction impact differently from one assessed over 10. A server assumed to run at high utilization allocates its embodied impact across more work than one sitting idle. A low-carbon grid makes manufacturing relatively more important. A carbon-intensive grid increases the weight of operating electricity.

Cooling results depend on climate, water source, operating temperature, equipment design, and final heat rejection. The cooling label alone cannot define the lifecycle result.

Data quality creates another constraint. Microsoft’s account of the Nature study says some suppliers did not provide all requested information, requiring methods to estimate gaps. Google’s hardware analysis combines primary bills of materials and supplier information with secondary databases and proprietary process models.

This is normal LCA work, not evidence that the method is useless.

It does mean that two polished carbon figures may not be comparable unless their boundaries and assumptions align.

The word lifecycle can create an illusion of completeness. Every assessment still leaves something outside.

Google Cloud’s customer carbon reports, for example, include upstream embodied emissions from data-center equipment and buildings. They exclude downstream end-of-life emissions, networking equipment outside Google data centers, and the embodied emissions of electricity-generation infrastructure. The methodology publishes those exclusions rather than presenting the result as a total footprint of everything involved.

That is what trustworthy lifecycle reporting looks like.

It defines the frame.

It does not pretend the frame contains the world.

Ask what has to be replaced

Modularity can make the lifecycle question more visible, but it does not answer it automatically.

A modular data center still contains long-lived and short-lived elements. Its structural enclosure, electrical systems, cooling equipment, networking, servers, storage, and accelerators may each follow different schedules.

The potential advantage is separability.

Can computing hardware change without discarding the infrastructure around it? Can a failed component be repaired independently? Can cooling or power systems adapt to another hardware generation? Can an older server move to a workload that suits it? Is there a defined route for equipment leaving service?

Those possibilities depend on design, maintenance, compatibility, contracts, and operating practice. The word modular does not prove they exist.

Modularity divides infrastructure into clearer commitments, while factory integration and site commissioning determine whether those boundaries work in practice.

Policloud develops and deploys physical, modular data-center infrastructure for defined sites.

For an infrastructure buyer, the responsible commercial questions are practical. Which parts are expected to outlive the first servers? What can be repaired, upgraded, or reused independently? Which lifetime assumptions sit behind the environmental calculation? How heavily will the hardware be used? What operating saving would justify early replacement? What happens after equipment leaves the site? Does reporting distinguish reuse from recycling?

These are commercial questions because replacement determines capital, downtime, compatibility, maintenance, and risk.

They are environmental questions for exactly the same reason.

A data center’s footprint is shaped by what has to be built again.

The meter starts late

Operational efficiency remains indispensable. Electricity and water accumulate across every hour a data center runs. Better cooling, power distribution, hardware, software, and utilization can reduce those demands substantially.

But the first reading on the meter arrives after much of the infrastructure already exists.

Concrete has been poured. Steel has been formed. Chips have passed through fabrication plants. Servers have been assembled. Cooling and electrical systems have been manufactured. Equipment has crossed supply chains and reached the site.

Later, some objects will fail. Others will remain functional but become uneconomic. Some will find second uses. Some will be dismantled for parts or materials. The building may remain while several generations of hardware pass through it.

PUE cannot describe that history.

WUE cannot describe it either.

A lifecycle assessment can bring more of it into view, provided its assumptions and exclusions remain visible.

The strongest data-center decision is not always the one with the lowest operating ratio, newest hardware, or longest possible equipment life.

It is the one that understands the exchange between manufacturing, operation, useful work, replacement, and retirement.

A data center does not begin when the first server switches on.

It begins when materials are extracted and infrastructure is made.

It does not end when a dashboard stops counting electricity.

It ends only when we account for what remains, what moves on, and what has to be built again.