Dissolve Microsoft and Google
into tools you own.

The problem with Microsoft 365 and Google Workspace is that the layers are closed, and that the key (identity) is concentrated in one vendor's hands. The bundle is the amplifier that spreads both across every layer.

The Introduction part moved embedded logic out into Python and made core logic something you could write yourself. The Independence part widens that hands-on power to the whole company. It unties identity, documents, sharing, mail, meetings, web, data, and AI from a single contract and puts them back on your side. From here on it is not "writing code" but "standing up the foundation."

There is one thing to do: untie the closed bundle into open tools, and move the key into your own hands. The force that does the opening is AI. It opens the Office suite and the core business systems the same way. This chapter is the map. It lays out, up front, what each layer maps to and which chapter stands it up.

The lock-in is closedness, and someone else's key

Microsoft 365 is convenient because login (Entra ID) connects straight into documents (Office), documents into sharing (SharePoint), sharing into mail (Exchange), and AI (Copilot) into all of them, all on one account, in one straight line.

Google Workspace has exactly the same shape. A Google ID connects straight into Gmail, into Drive, into Meet, into Gemini. Only the names differ; the binding is identical. One account, with documents, mail, meetings, and AI all chained together inside one vendor.

Be precise here. Bundling, by itself, is not the sin. Tools do work because they connect, and the stack this Independence part stands up also gathers authentication behind one gate and joins its tools together. A bundle turns dangerous when what is bundled has two properties.

First, it is closed. The formats are proprietary, the code is unreadable, the data sits in someone else's cloud. You cannot verify what happens inside, and you cannot carry it all out. An open bundle can always be untied. A closed bundle has its exits sealed.

Second, the key is in someone else's hands. Every layer hangs from one gate, Entra ID or Google ID. To touch a document or read your mail, you pass through another's door first. Whoever holds the key holds the pricing, the policy, and the life and death of your account.

Nor is this structure unique to the Office suite. The core business systems stand the same way. The code is unreadable and the specs undocumented, which is closedness. The understanding and the maintenance sit with the SIer, which is someone else's key. On both sides of the company's information base, office and core, closed things have hung from other people's keys.

And the bundle amplifies both across every layer.

• A price hike hits every layer at once. There is nowhere to escape
• A data-policy change hits every layer at once
• One vendor's outage stops every layer at once — one single point of failure for all of them
• Close the gate, and you are locked out of every layer at the same time
• The vendor AI's judgment (Copilot / Gemini) seeps into every layer

So the way out follows. Split each layer into an open tool, and move the key into your own hands. Open means you can verify and carry out. Your own key means you cannot be locked out. And once untied, each layer can be replaced on its own, and if one falls, the others keep running. This is the same shape as one person plus AI, at the scale of the company: autonomous N beats centralized 1.

Opening what is closed — that is AI's role

Why does it come apart now? Closedness worked as a rampart only because the cost of opening was too high for humans. Reverse-engineer a proprietary format. Read code no one can read. Reconstruct undocumented business logic. Each was a multi-year, multi-million job, which is why "don't touch what's working" stayed correct for so long.

AI crushes exactly that cost.

• It opens proprietary formats. The Office / Docs formats are split into things you read (adoc), tables you work in (a grid), and pages you print (templates) (2-07), and AI externalizes the embedded macros and logic into Python (the Introduction part; 2-04)
• It opens unreadable code. A local LLM reads the legacy core's code, SQL, and procedure manuals and extracts the business knowledge into Markdown (2-12, 2-16)
• It opens imprisoned knowledge. Paper, images, and tacit know-how become structured information through OCR and dialogue (2-15)

The Office suite and the core systems stand on the same structure, a closed bundle hanging from someone else's key, and AI opens both with the same operations. Read, extract, translate. What AI does best is, precisely, the work of unlocking.

The same goes for the key. What kept the key out of your hands was that an ordinary company had no way to stand up and operate its own gatekeeper, meaning an identity base. That operation, too, now has AI as a partner (see "one person + AI" below). The power to open what is closed, and the power to hold the key. AI returned both to your own hands. That is why the Independence part can be written now.

Vendors will not open themselves — so grow open tools at AI speed

If Microsoft and Google offered their suites as open components, company IT would become easy overnight. Open the formats, hand back the key, make each layer swappable. The same holds if the SIer delivered its work as readable code and documents.

It will not happen. Being closed and holding the key is the business itself. To open up would be to fill in their own moat (the structure in which lock-in is itself the product is covered in detail in 3-05). The road that waits on a vendor's goodwill is structurally closed.

So the road runs the other way: grow the open tools, at AI speed. AI's role is not only to open what is closed. It runs fastest when growing what is already open. OSS exposes its code and its specs, so the AI you bring along can simply become a developer on it. A missing feature gets written with AI. A habit that does not fit your business gets fixed with AI. What used to be OSS's weakness, "if it itches, you scratch it yourself," became the fastest path of improvement the moment AI joined as a partner.

With closed tools, that path is walled off. Bring your AI along and it still cannot touch the insides. You file a request and wait on the vendor's roadmap. The gap between open and closed tools did not narrow when AI arrived. It will keep widening, at AI speed.

You do not need to wait for the vendors to open up. Grow the open tools, at AI speed.

AI is separate infrastructure, not a feature inside the bundle

Reality is moving in the opposite direction. The vendors are embedding AI not as a tool that opens, but as a tool that re-tightens the bundle. The vendor AI sits on top of the stack, stitches the closed layers together through itself, and removes one more reason to untie. And much of the existing IT profession flows the same way, because proposing vendor AI on top of the familiar closed stack is the path of least friction. The opening move does not come from the inside.

How wrong this move is comes into focus once you correct one analogy. AI is usually likened to the industrial revolution, machines replacing labor. But when the question is where AI belongs, the right precedent is an information revolution, the same kind as movable-type printing. The printing press was not a convenient feature added to the scriptorium. It stood alone as a new infrastructure for handling text, and the existing flow of information reorganized itself on top of it. Nobody set a press in the corner of a copying workshop and called it faster manuscripts. The OS and the office suite are infrastructure, the place where information sits and moves. And AI is another, separate infrastructure, the one that reads, transforms, and produces information. Vendor built-in AI embeds one infrastructure inside another as a feature. It demotes the new infrastructure to an accessory of the old. Separate infrastructure stands separately, reachable from every tool. That is why this part of the series stands AI outside the bundle, not inside it, and last (2-16). That placement is a consequence of this reading.

The reading has a sequel. Movable-type printing had a preparatory stage of its own. Paper spread, and manuscripts spent centuries accumulating text. What the press detonated was that accumulation. In the same relation, the decades called the "IT revolution" were the preparatory stage of the AI revolution (the "completion" of 1-01, restated from the AI revolution's side). And the preparatory stage's greatest legacy is not the closed suites. It is OSS, the open commons of code and knowledge. The new infrastructure runs fastest on exactly this open accumulation. Which makes "grow the open tools at AI speed" not a detour but the main current. Seen this way, the treatment the IT industry gives AI, a press set in the corner of the scriptorium, also explains itself. The custodians of the preparatory stage are trying to fit the next revolution into a corner of their own workshop, the usual reflex.

Stand the base first, then write only the difference with AI

The same reading names one more waste: having AI write code on the spot, from nothing, pile upon pile. Live coding alone only reinvents the world's average software at premium compute. The thinner the structure you hand AI, the more its output converges on the average.

There is one use that compounds: stand proven open tools as the base, and write only the missing difference with AI (the OSS-first move of 1-05). AI stood up as separate infrastructure runs fastest on tools that were also stood up separately. This chapter's map is the list of that base.

The map — dissolving Microsoft and Google into independent OSS

Untie the bundle and the layers of Microsoft 365 and Google Workspace land on the same independent OSS. Replace the two left columns with the same right.

One row on the right is not OSS: Cloudflare Pages, on the publishing side of the web (2-11). That is a borrowed window, not a tool you hold. The same chapter also lays out the other route — Caddy on the one machine from 2-02, publishing from your own side. Decide separately what to borrow and what to hold — that is what 2-11 is about.

Some chapters do not appear in the table at all: 2-14 (electronics to IoT), 2-15 (preparing the information), and 2-17 (deciding how far AI runs). None of them has a matching suite layer, but all three are part of the Independence part, and they are in the order below.

The top row is the layer that is new. You take one company PC, put Debian on it, and hand it to the AI. The tools that follow are stood up on that one machine (only the self-hosted LLM goes on a separate server). With a suite you never had a machine of your own, because everything ran in the vendor's cloud. The document layer is not one tool stood up but a way of holding content: things you read as AsciiDoc in git, tables you work in staying in a grid, pages you print poured from templates. That is 2-07's job.

The tools on the right are separate open tools built by separate organizations. You can read inside them, the formats are open, and the data can be carried anywhere. So one vendor's decision cannot ripple into the others, and swapping any one for something else changes nothing around it. Open, with the key in your own hands. That is the point, and the untied bundle is its consequence.

This chapter is the map. It includes no build steps. The installation, config, and migration for each layer live in that layer's own chapter. Here we fix only which layer maps to which, and in what order they untie. Microsoft or Google, the destination is the same, so whichever suite holds you, the road ahead merges into one. And what each chapter fixes is the method, not an exhaustive command list. Ask the AI for the fine steps each time you work. That is also why the Google-side specifics, Gmail and Drive, look thin: when the method is the same, the AI fills in the details. Fattening the manual is itself the old common sense.

What changes is not the cost but the control

Untie it yourself and the monthly structure changes. Microsoft 365 and Google Workspace both bill per seat per month. At list price, Microsoft 365 Business runs ¥1,049 (Basic) to ¥3,298 (Premium) per seat per month — after the July 2026 revision, excluding tax, annual commitment averaged monthly. Google Workspace Business Standard is ¥1,600 per seat per month on an annual plan, with Gemini included in Business and above since March 2025; on the Microsoft side, Copilot is sold separately on top. All of it grows linearly as you add people.

A full self-hosted set is the fixed cost of one server — with the machine of 2-02, just the electricity and the line. It barely grows as you add people.

But cost is not the point. The point is that it is open, and the key is in your own hands.

• No one else holds life-and-death power over your entrance (auth)
• One vendor raises prices, and you replace only that one layer
• One vendor has an outage, and the other layers keep running
• One vendor changes its data policy, and the effect stays inside that layer
• The AI's judgment is something the company chooses

Inside the bundle none of these five works. You may want to replace a single layer, but the only way is to migrate every layer at once, which is effectively impossible. Untied, you swap that one tool and the rest is untouched.

The order of untying starts with the machine

You do not have to do it all at once. Go in order of what is easiest to pull out of the bundle, one at a time. The Independence part is structured in exactly that order.

1. The machine (2-02). Take one company PC, put Debian on it, and hand it to the AI. Everything stood up after this sits on that one machine
2. Data layer (2-03). PostgreSQL, SQLite, DuckDB. Analysis, RAG, scheduling, and the core systems all sit on this, so it goes first
3. Logic (2-04). Python and Flet. Move the macros and charts buried in Excel and Word outside, and put a screen on where one is needed
4. Auth (2-05). PocketBase. The shared gate for every app. Move this to your side and the root of the bundle is cut
5. Sharing and versioning (2-06). Forgejo + Zed. Folds in SharePoint and Drive
6. Documents (2-07). Things you read as AsciiDoc text, tables you work in in a grid, pages you print from templates. Office and Docs formats pass through at the entrance and the exit
7. Mail (2-08). Stalwart. Keep the contents of your communication on your own disk
8. Meetings and calendars (2-09). Jitsi, Radicale. Meetings and shared calendars on your own side; booking is written in 2-12
9. Build the web (2-10). Content in AsciiDoc, the frame in HTML and CSS, Python connecting the two
10. Publish the web (2-11). Your own machine with Caddy, or Cloudflare Pages. Decide separately what to borrow and what to hold
11. Core logic (2-12). FastAPI. Turn Power Apps and Apps Script back into readable code
12. Diagrams and documents (2-13). Mermaid, Marp, CAD. Diagrams, slides, and enclosures, all made from text and code
13. Electronics to IoT (2-14). Only where the field needs it. Think in Python on the board, take the values in with FastAPI, store them in 2-03
14. Prepare the information (2-15). OCR, classification, codifying tacit knowledge. Before you put AI on it, build information worth putting it on. Preparation is the main body, AI the last move
15. AI (2-16). Local LLM + RAG. Hold AI without your data leaving the building
16. Decide how far AI runs (2-17). Do not run it autonomously; freeze what is settled into code

Run each step in parallel, the way 2-12 describes. Do not stop the old suite. Run the new alongside it, confirm the same work flows through, and only then cancel the old. Time it to the renewal date. That, too, follows 2-12. You do not need to switch all at once. Each layer you untie loosens the bundle a little more.

Operating it — one person + AI

The obvious question arises. With this much self-hosted, who maintains it? The answer is one person plus AI. That new unit of work — one person plus AI — applies directly to running the company's infrastructure.

Why does one person suffice? Three reasons.

• Every piece is a standard open tool. Each installs from Debian's apt or as a single file from its project, and runs under systemd. No Docker (the reasons are in 2-02). The AI writes the configuration, sets up DNS and DKIM, reads the logs, and isolates the fault. Your operations partner is the AI
• Because the bundle is untied, faults do not cascade. With a suite, one vendor's trouble drags everything down. Here, mail lives even if Forgejo falls, and meetings continue even if the AI stops. You fix them one at a time, independently
• Visible, readable, testable. Config and logs are in your own hands. Unlike a black-box vendor AI, you can read inside and fix it together with the AI

The heavy parts deserve honesty too. Operational load concentrates in two places, mail and the course server (BigBlueButton). Mail delivery (DKIM, SPF, reputation) is delicate, so you can offload just the outbound to an external relay. The course server is heavy, so stand it up only for the duration of a course and tear it down after. The rest you can mostly leave alone once it is up. And the rest of operations, meaning backup, monitoring, updates, and failure, need not be written in the idiom of the old operations manual. The premise has changed here too.

Protect only the data and the specification. The implementation and the environment can be rebuilt at any time by AI, from the spec and the OSS (2-12). So replicate only what cannot be regenerated: the databases, the files, the mail, the repositories, and the business rules in Markdown, daily, to another box (2-02). That is all. Restore testing is not a ritual either. Ask the AI to rebuild everything on a blank box from the spec and the backup, and that is the restore test.

Monitoring needs nothing more than readable logs. Standing up a separate monitoring stack is the old common sense. The logs are all in your hands, liveness checks and notifications are a few dozen lines the AI writes, and log anomalies are something the AI reads. Updates, too, are deliberate acts. When you raise a version, have the AI read the release notes and verify alongside, parallel-run style (2-12), before switching. Things do not get upgraded on you. You upgrade them. Secrets, meaning passwords and keys, live in an environment file and never leave the box. Write that one line of policy first.

Availability is taken by speed of rebuild, not by redundancy. If the box dies, rebuild on a spare from the spec and the backup. When recovery runs at AI speed, you do not need a cluster. Concentrating on one box is fine precisely because the box is disposable and the assets, data and spec, are replicated.

The box itself, meaning taking one company PC, putting Debian on it, and handing it to the AI, is 2-02's job. The floor under that box, installing the OS, SSH, the basics of defense, and protecting the data, is specified by Learning Debian with Claude, Server Edition. Here too, the generic is handled by reference.

This is where one person plus AI holds. You do not need a siloed IT department. One person who understands the business holds, with the AI as partner, everything from auth to mail, meetings, AI, and the database. Individual independence holds at the level of company infrastructure. One person plus AI operates this whole set of open tools. Compared with handing the suite to one vendor, the effort is the same. Only the control moves to your side.

This foundation is also the foundation of the core systems

What you have assembled becomes, directly, the foundation for rewriting the core systems. The parallel-run rewrite 2-12 describes actually assumed a place to stand, a platform, and that place is fully in place by the end of the Independence part.

• The DB the new core runs on. PostgreSQL + pgvector (2-03)
• The runtime. FastAPI / Python with a Rust layer beneath (2-12)
• Versioning and CI. Forgejo (2-06)
• Auth. PocketBase takes on login for the new system, all in one place (2-05)
• Extracting business logic. Read legacy code, SQL, and procedure manuals with a local LLM + RAG (2-16) and emit Markdown, without the source ever leaving the building

In fact, all the core systems and Microsoft or Google ever shared were just two things: auth (Entra ID / Google ID) and document sharing (SharePoint / Drive). The world of business systems and the world of the office are mostly separate by nature, joined only at those two seams.

Those two are replaced, in the Independence part, with PocketBase and Forgejo. That means the seams are already on your side. The new core system authenticates with the same PocketBase as the office side and shares documents and versions through the same Forgejo. The two worlds meet again at a single point, with no vendor in between.

The two seams are not the same weight. Sharing is a place to put things; auth is the key. A place to put documents can be moved later, any number of times. But auth is the single point from which every app, login, and permission in both worlds hangs. As long as that is held by someone else, no matter what you self-host, the entrance belongs to another.

So the move that really tells in the Independence part is auth to PocketBase (2-05). The moment you move the seam of identity to your side, both the core and the office authenticate against your own gate. It is exactly here that Microsoft and Google try to dig in deepest, because identity is the root of the bundle. Hold this, and the rest is a matter of time.

To be clear, PocketBase also concentrates authentication at a single point. The concentration itself cannot be removed. Everything is convenient because every app uses the same gate, and that holds for the self-hosted stack too. The difference is two things only. The key is in your own hands. And because it is open, it can be replaced at any time. Back to the anatomy at the top: concentration was never the problem. Closed concentration, in someone else's hands, was.

In the AI-native era, rebuilding becomes the default

Finally, step back one notch. Rewriting the Microsoft or Google suite is not a special decision. In the AI-native era, rebuilding becomes the default.

Two reasons interlock.

First, the suites are structurally anti-AI-native. They lock content into Office and Docs formats, imprison data in the cloud, and wire the vendor AI directly into work with no verification layer. None of this is accidental. It is a design that keeps content away from where AI can reach it: plain text, open formats, local execution, readable code. The more you try to make AI a colleague, the harder you hit this wall.

Second, the cost of rewriting has fallen by an order of magnitude (2-12). The AI extracts the business logic, translates it to Python, and writes the tests. A rewrite that could once only be thought about in years becomes something one person on the ground plus AI can turn.

The old structure does not fit AI-native, and rebuilding is cheap. When those two overlap, the conclusion is one. Keeping it becomes the unnatural choice. "Don't touch what's working" was once correct only because rewriting was too expensive. Now that the premise is gone, it is the reason not to rebuild that needs explaining.

This is not hostility toward Microsoft or Google. It is the natural turn in which the AI revolution rebuilds and inherits what the IT revolution stacked up (the Introduction part). The question is not whether, but when and led by whom. Leave it with the vendor, or rebuild it on your own side. That is all.

This way of untying can be checked in a public repository

This way of untying the bundle exists as a toolkit: the public repo aiseed-migration-kit (aiseed-dev/aiseed-migration-kit). It carries the static-site migration pipeline (ingest, classify, Markdown, build, publish) and the form-sheet method for inquiries, where instead of a web form you accept an xlsx sheet by mail and read it as machine-readable data, as a CLI plus a design document. The DESIGN.md holds this chapter's mapping table with its reasoning, covering identity, boundaries, and placement, so you can read it first and then fit it to your own organization. The document-side reference is kura (2-07); the business-system-side examples are seminar-kit and mfg-kit (2-12). Every design put into words in these chapters can be checked in code.

How to check you are done

This chapter is done when the following four are true. The work happens on paper or on screen. No server is stood up yet.

1. You have written the tools your company uses today into the two left columns of the mapping table, covering machine, auth, documents, sharing, mail, meetings, web, data, core logic, and AI, on whichever side applies, Microsoft 365 or Google Workspace
2. Each of those rows carries the right-hand column (the self-hosted OSS) and the number of the chapter that stands it up. Layers you do not use can stay blank
3. You have written down the contract renewal date for each layer. Parallel running has to finish by that date
4. You can list the order of untying, in sequence, in your own words. The first is the machine (2-02); after that you may reorder to suit your own company

Nothing runs in this chapter, and there is no command to check. One completed table is enough to move on.

What the human holds

Values the human supplies

• The list of SaaS contracts in force: Microsoft 365 or Google Workspace, and which of its layers you actually use
• The renewal date and the per-seat monthly price for each layer
• The decision on the order of untying. Which layer you start with is a human call, made on the company's circumstances

Actions the AI states before performing

• Cancelling the old suite. Nothing is cancelled before parallel running has shown the same work flowing through the new side
• Exporting data out of the old suite, and deleting it at the source. Delete only after confirming the copy opens on your own side

Versions checked, and when

• No tool version is fixed in this chapter. The table carries product names only, and the versions are fixed in the chapters that stand each one up: PocketBase, Forgejo, Zed, Stalwart, Jitsi, Radicale, Cloudflare Pages, PostgreSQL, SQLite, DuckDB, Polars, FastAPI, and a local LLM
• These steps were written on 2026.07.01
• If a version has moved on, have the AI check the official procedure before proceeding

Summary

Business Microsoft 365 and Google Workspace are SaaS suites that bundle closed layers into one vendor and hang all of them from a single key, identity. The core business systems have stood the same way. The danger was never the bundling. It was a closed bundle hanging from someone else's key. And opening what is closed is AI's role. The Independence part, working with AI, unties that bundle, layer by layer, into open OSS and moves the key to your side, and the two suites land on the same right-hand side.

• Machine: the vendor's cloud to one Debian PC (2-02)
• Auth: Entra ID / Google ID to PocketBase (2-05)
• Documents: Office / Docs to adoc + git, a grid, and templates (2-07)
• Sharing and versioning: SharePoint + GitHub / Drive to Forgejo + Zed (2-06)
• Mail: Exchange / Gmail to Stalwart (2-08)
• Meetings and calendars: Teams / Meet to Jitsi and Radicale (2-09); booking in 2-12
• Building the web: Power Pages / Sites to AsciiDoc + HTML/CSS baked by Python (2-10)
• Publishing the web: Power Pages / Sites to your own machine with Caddy, or Cloudflare Pages (2-11)
• Data layer: Azure SQL / Cloud SQL to PostgreSQL and SQLite (2-03)
• Data analysis: Power BI / Looker to DuckDB + Polars (2-03)
• Logic: Excel macros / VBA to Python, with Flet for the screen (2-04)
• Core logic: Power Apps to FastAPI (2-12)
• Diagrams and documents: Visio / Drawings to Mermaid, Marp, CAD (2-13)
• AI: Copilot / Gemini to a local LLM + RAG, on a separate server (2-16)

One to one, replace the left with the right. The tools on the right are separate open tools built by separate organizations, readable inside and portable out, so one vendor's decision cannot ripple into the others. This is not about efficiency. It restates one person plus AI at the height of the company's foundation. Autonomous N beats centralized 1.

Untie the closed bundle into open tools. Move the key into your own hands. The force that opens, AI, is already at hand. One at a time, at your own pace. With each layer untied, the company is that much less a vendor's hostage and that much more able to move on its own judgment. The next chapter stands up the first one. Take one company PC, put Debian on it, and hand it to the AI. Everything after that sits on that one machine.

Related articles

• 2-02: Give the AI a PC of Its Own — The Machine the Independence Part Runs On
• 2-03: Lay the Foundation — SQLite, PostgreSQL, pgvector, DuckDB, Polars
• 2-07: Take Documents Back
• 2-12: Build an API — Expose Core Logic with FastAPI
• Structural Analysis 08: Subtracting the Enterprise IT Tax