Your content and submitted data
You retain the content and data you provide. Rehost uses them to operate the agreed service under the customer agreement and public policies.
A managed software relationship with the boundaries written down.
Rehost builds and operates the agreed app, website, and customer system. The proposal defines the price, work, accounts, ownership, evidence, and what happens when the service ends.
The short ownership answer.
These public boundaries apply unless a signed customer agreement states different project-specific terms.
Rehost service software
Rehost owns its service software, code, and designs unless a signed customer agreement grants a different license or handoff.
Accounts and transition
The agreement identifies whose name each domain, payment account, app-store account, and vendor account uses, plus the export and shutdown steps at the end.
Six rules for how the relationship works.
The goal is simple: remove software work from your staff without hiding the limits, responsibilities, or exit path.
Name the accounts before the build starts.
The proposal lists the domain, app-store accounts, payment processor, analytics property, customer records, and third-party services needed for the project. It states which organization controls each account and who pays each vendor.
Why this matters: Account ownership is too important to leave as a sales promise. Writing it down prevents confusion at launch and at the end of service.
Routine changes move by message.
Your staff does not manage a Rehost CMS for the routine work included in the plan. They send the request in plain language. Rehost makes the change, checks it, and publishes it through the managed service.
The trade-off: Your team gives up instant access to every setting. In return, it does not inherit another dashboard, password, training task, or maintenance queue.
Price, scope, and limits are written together.
The proposal shows the recurring price, commitment, included work, review responsibilities, taxes, and known third-party costs. A material change in usage or scope is discussed before it changes the bill.
Why this matters: A visible price is useful only when the buyer can also see what it covers and what would require a new decision.
The build and the operating work stay connected.
Rehost remains responsible for the managed hosting, monitoring, routine updates, app-store work, and agreed changes after launch. The same operating context carries from the build into the monthly service.
Why this matters: Software becomes expensive when every change starts with a new team rediscovering how the system works.
Evidence beats a blanket promise.
We use working previews, account records, analytics, change history, and customer evidence to show what has been delivered. Timelines and outcomes are reported as observed facts or scoped targets, not guarantees.
Why this matters: Search rankings, sales, adoption, and launch timing depend on factors no software team controls alone.
The ending is part of the agreement.
Before launch, the agreement identifies the commitment, notice, effective end date, exportable data, transferable accounts, any code license or handoff, and when Rehost-managed hosting and operations stop.
Why this matters: A clear exit is more useful than saying there is no lock-in while leaving the actual handoff undefined.
Verify the method against the source.
Pricing, customer evidence, and the public Terms provide the supporting detail behind this page.
Questions about ownership and the operating model.
The answer may depend on the signed customer agreement. This page says so when it does.
Is this a software methodology like Agile or Waterfall?
No. This page explains the operating relationship between Rehost and a customer. Rehost may use short internal delivery cycles, but the important customer-facing facts are the scope, responsibilities, review points, accounts, price, and end-of-service terms.
Do we own the Rehost code and designs?
Not by default. The public Terms state that Rehost owns its service software, code, and designs, while customers retain the content they submit. A signed customer agreement can describe a different license or handoff for a specific engagement. That written agreement controls the project-specific answer.
What data can we take with us?
The agreement should name the customer records, content, media, and operational exports included in the service. Rehost-managed systems can contain both customer data and Rehost service code, so the export list must distinguish the two.
Will the app or website keep running after cancellation?
Rehost-managed hosting and operations stop on the agreed date. Whether the software can continue elsewhere depends on the code license, repository access, infrastructure handoff, app-store setup, and transition support written into the customer agreement.
What is the downside of changes by message?
Your team cannot change every setting instantly. Requests follow the response expectations and scope in the agreement. This works well for teams that want the operating burden removed. It is a poor fit for teams that require direct, real-time control of every configuration.
Can enterprise agreements work differently?
Yes. Enterprise work can include dedicated infrastructure, security reviews, custom service levels, account structures, licenses, and handoff terms. Those differences must appear in the signed agreement rather than in a general marketing claim.