civis.ai migration · Findings
civis.ai migration · Findings
The reconnaissance is done. Eleven systematic sweeps across DNS, email, Pardot, the live site, our code, public registries, and three weeks of meetings. This page is what we found, what it means, and the two decisions that size the whole project.
They run at four different speeds, and the plan has to respect that. Every number on this page traces to a named source; anything unverified says so and is listed in section 14.
The Cloudflare rebuild approved on August 10 does most of the work. Pointing civis.ai at it and running permanent redirects from civisanalytics.com is configuration, and every step of it can be undone. Google already shows the query "civis ai" earning clicks at average position 2.0 with nothing live there.
Our mail stack is deeper than any plan knew: a Cloudflare Email Security gateway filters inbound mail before Google sees it, six vendors send as us, and our SPF record sits at 8 of a hard limit of 10 DNS lookups. A new domain starts with zero sending reputation and has to be warmed slowly on a protective subdomain. This lane needs weeks of calendar time and an owner it does not currently have.
The platform login, the API that every customer's code calls, customer VPNs, and single sign-on all live on the old domain. The published Python SDK hardcodes the API hostname into every copy customers have ever installed. Moving any of it is an engineering project on customer calendars, and the rebrand does not require it. So the old domain never fully retires: it keeps DNS, mail authentication, and redirects indefinitely.
First: does the legal entity name change, or only the domain? No meeting or document on record has discussed it. Second: does Google Workspace adopt civis.ai as its primary domain, or carry it as an alias? The alias path is reversible and incremental; the primary swap renames every user and everything keyed to their addresses. Both decisions belong to leadership, and both are answered "unknown" today.
The spine of the document. Eleven sweeps produced this inventory; the risk column is about what happens if the surface is handled wrong, and "out of scope" means the recommendation is to leave it alone in this project.
| Surface | Today | Target | Owner | Risk |
|---|---|---|---|---|
| Marketing website | Webflow, moving to Cloudflare Pages | civis.ai primary, old domain redirects permanently | Marketing | Low |
| civis.ai domain | Parked at Namecheap, expires Dec 2027, unexplained certificates issued in June | Live primary domain with named renewal owner | Needs an owner | Medium |
| Corporate email | Old-domain addresses, security gateway in front of Google, strictest DMARC policy | Alias or primary decision, then dual domains kept for years | Leadership + email admin | High |
| Marketing email (Pardot) | Sends as the old domain; two live tracker domains; all 135 templates reference it | New warmed sending subdomain, new tracker, updated templates | Marketing | High |
| Third-party senders | Six vendors authorized to send as us, plus five unattributed IP blocks | Keep, move, or retire decision per sender on the new domain | Needs an owner | High |
| Platform, API, VPN, SSO | All on old-domain hostnames customers have hardcoded | Do not move in this project | Engineering | Out of scope, flagged |
| Help center | Zendesk on a old-domain subdomain, years of indexed articles | Later host mapping; vendor fallback exists | Marketing + support | Low |
| Status page | Already broken: inactive page and a certificate error, today | Fix or retire regardless of the migration | Needs an owner | Broken now |
| Forms and redirects in Pardot | 44 form success redirects, 29 landing page redirects, 26 vanity destinations point at the old site | Update after web cutover; old links keep working through redirects | Marketing | Medium |
| Analytics and consent | Two tag manager containers, one analytics property, consent tool licensed per domain | New domain added to consent license, containers audited, measurement kept clean through the move | Marketing | Medium |
| Code and templates in our repos | Canonical email wrapper, blog pipeline, about 30 send scripts, and the new site's own config stamp the old domain | Cutover-day sweep list, already written | Marketing | Medium |
| Public artifacts | Python and R packages, 83-repo GitHub org with a verified domain, social profiles, Wikipedia, Crunchbase | Rolling metadata updates; one package registry requires a living maintainer address | Engineering + marketing | Medium |
| Campaign microsites | Five marketing subdomains on the old zone | Case by case; most stay or retire quietly | Marketing | Low |
| Legal and compliance | FedRAMP records, DPAs, an active procurement questionnaire, and a partner certification all name the current identity | Depends on the entity-name decision | Leadership | High, unscoped |
| Brand collateral | Signatures, decks, one-pagers, video bumpers, business cards | Rolling refresh after cutover | Marketing | Low |
The Webflow to Cloudflare rebuild has its own approved plan and is nearly staged. Only what changes because the hostname changes is listed here.
A full crawl of all 131 live pages found zero structured data and zero og:url tags. The rewrite is canonicals, the sitemap, 32 absolute self-links, and 8 form redirect attributes. Social card images live on a third-party CDN and survive untouched.
The new site's config defaults its canonical origin to the old hostname, 78 absolute internal links carry it in content, and 92 pages still hotlink assets from the old platform's CDN, which dies if that subscription is cancelled. All three are on the written cutover sweep list.
Two draft pages are publicly crawlable, three password-protected pages sit in the public sitemap, one press release still links to itself over plain http, and two different help center hostnames are used interchangeably in blog posts. The move is the moment to drop all of it.
The bare domain now resolves through CloudFront where the master plan recorded a single address. Someone changed apex hosting after August 3. Confirm who and why before cutover planning trusts the older document.
The master plan contains zero mentions of MX, Google Workspace, SPF, DKIM, or DMARC. This section is the missing plan, built from what the mail stack actually looks like.
Inbound mail does not go to Google first. It passes through Cloudflare Email Security, a filtering gateway confirmed from our live MX records against the vendor's own documentation. A civis.ai mail cutover has to be provisioned inside that tenant, inside Google, and in DNS, in the right order.
Google, the support desk, the marketing platform, the CRM, the ticketing suite, and the status page are all authorized senders on the current domain, plus five raw IP blocks nobody has attributed. Each one needs a keep, move, or retire decision on the new domain, and each costs DNS lookups we barely have.
The record sits at 8 of a hard limit of 10 lookups, and one provider has changed the shape of its record before, so real headroom is one. Recreating today's setup on civis.ai leaves no room for growth. The answer is the subdomain split described below.
Registry facts verified against the registry operator, registrar documentation, and a live registry lookup on August 26.
| Fact | Value | What it means |
|---|---|---|
| Registrar | Namecheap, with privacy-redacted contacts | Not the same place as our DNS. Who holds the account login is unknown and needs answering this month |
| Registered / expires | December 2023 / December 2027 | Paid up. Renewals run on two-year cycles, the .ai minimum |
| Registry | Anguilla's country domain, operated since January 2025 on a standard backend | Transfers, lookups, and DNSSEC now behave like mainstream domains; the manual-era quirks ended |
| Expiry behavior | Expired .ai names feed daily auctions | A lapsed renewal likely means permanent loss of the brand. With no IT function, renewal needs a named owner |
| DNS | Route 53, zone empty apart from delegation | Clean slate. Open choice: build the zone in Route 53 alongside our other domains, or move it to Cloudflare next to the hosting |
| Certificates | Two wildcard certificates for civis.ai were issued this June via AWS | Someone with AWS access provisioned them for an unknown purpose. Identify who before assuming this project has the only hands on the domain |
Records that will change get short lifetimes a day ahead, so a mistake reverts in minutes and the change itself lands fast.
The old domain's registration, its DNS zone, and the redirect layer stay forever. The product, VPN, support desk, and historical email links all live there, so it was never a candidate for retirement.
It is the live marketing link-tracking domain, in production, serving nearly a thousand hosted assets. It stays exactly as it is.
The full baseline and mechanics live in the approved master plan; these are the facts that set the risk level.
A read-only audit of the full marketing automation library, plus the analytics stack the crawl actually observed.
| Object | Total | Reference the old domain | Action |
|---|---|---|---|
| Email templates | 135 | 135 | Update wrappers and senders once the new sending domain is live and warmed |
| Sent emails | 1,801 | 1,772 | History, immutable. Their tracked links must keep resolving forever |
| Forms | 62 | 45 | All 44 configured success redirects point at the old site; update after web cutover |
| Landing pages | 47 | 29 | Same treatment as forms |
| Vanity redirects | 54 | 26 | Update destinations; the short links themselves keep working |
| Hosted files | 966 | 1 | Nearly all served from the tracker domain that is not changing. No action |
| Tracker domains | 3 | 1 | Add and validate a civis.ai tracker. Never delete the old ones |
Completion actions, form error pages, automation rules, and the preference center are invisible to the API and need a by-hand audit in the marketing platform's own interface.
Every page loads two tag manager containers where the plan knew of one. Both need a hostname audit before cutover, and consent-gated tags need the consent tool to cover the new domain first.
The analytics property, search data, and sent-email statistics all stay attached to their accounts. What needs care is the overlap window: measurement configured so the two hostnames do not double-count while both are live.
The strongest single finding of the reconnaissance, and the recommendation that keeps this project safe.
The published Python client defaults every request to the API on the old domain, in every version ever released, on every machine it is installed on. The R client and the MCP server inherit the same dependency. Customer scripts, scheduled jobs, VPN configurations, single sign-on setups, and login bookmarks all point at old-domain hostnames. Each breaks on a customer's calendar, and each is owned by engineering.
So the recommendation is scope discipline: the brand, website, and marketing systems move; the product does not. Anything that would require a customer to act becomes a communication project with lead time, run by engineering, on its own schedule, if it ever runs at all.
Engineering is currently shipping a feature that serves customer reports on the customers' own domains, top of the roadmap and expected around now. It reworks the same hostname layer this migration touches, and no meeting or document connects the two efforts. One conversation aligns them; it should happen before either ships.
The public status page serves an inactive notice with a mismatched security certificate, before any migration work. Worth fixing or retiring on its own merits, and a reminder of what unowned infrastructure looks like.
Is the legal entity changing, or only the domain? Everything in this section scales with the answer.
Certificates issue automatically. Published legal pages redirect permanently so contract citations keep resolving. Vendor domain verifications, currently eleven separate records on the old domain, re-establish one by one as each vendor is touched. Compliance documents get the new URL at their next revision.
Contracts, data processing agreements, federal compliance records, procurement responses in flight this month, and the partner certification under review all name the current identity. A rename touches every one, needs counsel, and has no owner or estimate today. This document deliberately does not price it; it flags it.
An AI partner certification with logo rights is expected to resolve between mid-September and early October, applied for under the current name. Changing public identity mid-review risks the window. The partner conversation happens before any public change, and leadership owns it.
The security page advertises single sign-on by default and federal authorization. Identity configurations live in customer systems and agency records, all referencing old-domain hostnames. Out of scope here by the section 8 recommendation, and the reason that recommendation exists.
None of this gates the cutover. All of it needs a checklist so nothing ships with the old name after the new one is live.
Email signatures for every person, the canonical email wrapper, the registration page template, slide decks, one-pagers, video bumpers, and business cards. The wrapper and registration templates are already on the cutover sweep list; the rest is a rolling refresh.
The company pages on the major networks, the video channel, the encyclopedia entry, and the business databases that feed search knowledge panels all list the old site. Handles are verified; the website fields need a by-hand pass after launch.
The partner logo work lands in the same window as this project, and a customer summit is being discussed for November or December. Anything printed or announced for either should carry whichever name will be true on the day, which argues for deciding the naming question before the fall events are locked.
Roles only on this page; the named version lives in the internal findings document.
| Audience | What they hear | When | From |
|---|---|---|---|
| Leadership | This report, the two sizing decisions, and the risk register | Now | Marketing |
| Engineering | Product hostnames stay put; white-label coordination; the June certificate question; an inventory ask for identity and VPN surfaces | Before any plan gets a date | Marketing via leadership |
| Email administration | The lane cannot start until someone owns the mail tenant and Workspace. There is no IT function today and HR is covering | A leadership decision, now | Leadership |
| Staff | New addresses arrive as aliases, both addresses work, signatures update on a schedule | When the email lane starts | Marketing + HR |
| Customers | Nothing technical changes for them. A brand announcement, with account teams briefed for named accounts | Cutover week | Marketing + account management |
| Partners | Brand change notice; the certification partner hears first, before any public change | Pre-launch | Leadership and sales, by relationship |
No figure on this page is invented. Where the real number is not in hand, it says unverified, and pulling the invoice is the action.
The web lane fits the December to January window the marketing calendar already reserves. The email lane is calendar-elapsed warm-up time more than labor. Legal review, if the entity question goes anywhere, is unpriced and needs counsel.
The .ai renewal at two-year cycles, next due December 2027, price unverified. The old domain and its DNS zones continue indefinitely, already paid today. Whether the consent tool and the workspace plan absorb the new domain without new line items is unverified; both invoices need checking.
The old website platform's subscription ends after the transition, per the standing decision to keep it during the overlap. Its actual cost is on record twice with conflicting units and stays unverified here. Pull the invoice before any savings figure goes in a deck.
A gate is something with no rollback: it is prevented, never repaired. The four gates shape the plan's sequencing more than any preference does.
| # | Risk | Damage | How we detect it | Undo |
|---|---|---|---|---|
| 1 | New-domain sending reputation burned by warming too fast or cutting bulk mail over cold | The whole email program lands in spam for months | Mailbox-provider reputation tooling enrolled on day one, on both domains, plus bounce and open monitoring | No. Gate. Prevention is the plan |
| 2 | Breaking live mail on the current domain while adding records: the lookup limit, a bad policy edit, an MX mistake | Company-wide mail bounces silently under the strictest policy | Before-and-after record diffs, staged changes, header spot checks | Config reverts in minutes; messages rejected in the window are gone. Gate: two-person review on any mail-record change |
| 3 | Certification disrupted by renaming mid-review | Logo rights and the fall webinar anchor slip | One question to the partner manager, asked before anything public changes | No, within the window. Coordinate or wait |
| 4 | Losing the domain itself: unknown registrar account owner, no renewal owner, 2027 renewal | The brand goes to auction | Registry expiry watch; find the account owner this month | No, after the grace period lapses |
| 5 | Workspace primary-swap fallout, if that path is chosen over alias | External identities keyed to old addresses break piecemeal, including a package registry that can archive our client library over a dead maintainer address | Identity inventory before any swap | Partial only |
| 6 | Mail lost in the MX cutover window | Individual inbound messages vanish | Dual delivery verified before the change, test matrix during | No, per message. Gate |
| 7 | Collision with the white-label URL feature | Two incompatible domain architectures ship at once | The coordination conversation, held now | Yes, if caught before either ships |
| 8 | SEO dip deeper than modeled | Branded traffic slow to re-associate | Weekly search data against the recorded baseline | Yes. Redirects stay, recovery is time |
| 9 | Consent or measurement gap at launch | Compliance exposure, and blind analytics in the one window that needs them | Pre-launch checklist on the staging site | Yes, though lost data stays lost |
| 10 | Old tracked links rot if the old tracker domain or redirect layer is ever removed | Links in 1,801 sent emails and years of collateral die | A written keep-forever list | Yes, by never removing them |
This section is a feature. Each item names the assumption made and who can settle it.
If wrong: a legal workstream appears and this report undercounts the project. Needs leadership, probably with counsel.
Needs: a leadership yes, and a named email administrator to carry it.
Why it matters: renewal and transfer control live there, the record is privacy-redacted, and the historical DNS handover was informal. Answer this month.
Why it matters: someone with cloud access already has plans or leftovers touching this domain. Ask engineering.
Current answer on record: nobody; HR is covering IT. The email lane has no start date until this has a name.
Needs: someone who remembers the history to confirm what sends from them.
Needs: engineering confirmation, in the same conversation as the white-label coordination.
Timing on record: mid-September and October 1, from two different meetings on the same day. Leadership owns the conversation.
Action: check both invoices. Marked unverified in section 12.
Action: pull the subscription line before any savings claim goes in front of leadership. Two conflicting figures are on record.
Needs: a scheduling decision once the summit itself firms up. Nobody has connected the two yet.
Why: permanent redirects carry the link equity meanwhile; outreach is a post-launch nicety, done with tooling not yet authorized.