Migration vs greenfield — two fundamentally different installation engagements
Operators frequently treat "install PowerMTA on my server" as one thing. It is two things, and the operational complexity differs by 3-5×. Greenfield install is what most people picture: clean server, fresh installation, configuration tuning, handover. Migration install is greenfield install plus moving data, preserving sender reputation, validating the new system matches the old system's behavior, and decommissioning the old environment without service interruption. Understanding which type your engagement is determines the right scope and pricing.
Greenfield install — the simpler engagement
You provisioned a new server, you have no existing email infrastructure to preserve, you want PowerMTA + MailWizz installed and ready to send. The scope is what we install on this new server: OS hardening, application install, configuration tuning, DNS records published, FBL registration, smoke test, handover. Timeline 2-5 days depending on whether it is a single-product install or the combined stack. Pricing fits cleanly into the €149-€499 range. About 60% of our installation engagements are greenfield.
The greenfield install path has predictable scope because there is no legacy system constraining decisions. We pick the OS we prefer (AlmaLinux 8/9), the database version we recommend (MySQL 8.0), the cache backend that performs best (Redis 7). Operators who have engineering opinions get to specify; operators who do not want to make these decisions get sensible defaults. The runbook documents what was chosen and why so future migrations have context.
Migration install — the complex engagement
You have an existing email infrastructure (CentOS 7 + PowerMTA 5.x + MailWizz 1.x, or a SendGrid account, or a competing self-hosted platform) and you need to migrate to a new server with current versions. The scope expands meaningfully: greenfield install on the new server, plus data migration (subscriber lists, suppression lists, campaign history, template library), plus reputation preservation (DKIM key handling, IP warmup planning, parallel-send strategy), plus validation (sending behavior matches the old system, deliverability metrics do not regress), plus old-system decommissioning. Timeline 7-14 days; pricing typically €600-€1,500 depending on data volume and complexity.
The migration install path has unpredictable scope because the legacy system's quirks determine what work is actually required. A clean SendGrid-to-MailWizz migration is mostly data export and reputation transfer; a CentOS 7 + PowerMTA 5.x + MailWizz 1.x migration is OS rebuild plus PowerMTA major version upgrade plus MailWizz major version upgrade plus database schema migration. We always do a discovery phase before quoting migration installs because the scope depends on what we find when we audit the legacy system. Operators expecting fixed-price migration quotes without discovery are signaling they have not done one before.
The hybrid pattern — install fresh, migrate selectively
Some operators run both old and new systems in parallel for 30-90 days. New campaigns go to the new system from day one; subscriber data migrates progressively as old campaigns complete; sender reputation transfers gradually via shared-IP overlap during the transition window. This pattern reduces risk meaningfully but requires running two systems simultaneously, which adds operational complexity during the transition. We have done this pattern for operators where migration risk was unacceptably high — typically large established lists where deliverability degradation would cost meaningful revenue.
The hybrid pattern is not always the right answer. For smaller operations (under 100K subscribers, under 1M emails/month), the operational complexity of running parallel systems exceeds the risk reduction. For larger operations (500K+ subscribers, 5M+ emails/month), the parallel-systems pattern is frequently worth the complexity because the cost of getting migration wrong is meaningfully larger than the cost of running two systems for 60 days.
What discovery actually accomplishes for migration engagements
Before we quote a migration install, we do a paid discovery phase (€150 deposit, applied to engagement) where we audit the legacy system, document what is currently running, identify migration risks, and produce a written migration plan. The audit covers: OS version and patch level, application versions and customizations, database size and schema state, IP reputation and warmup history, DNS configuration and record state, FBL registration status with each ISP, integration points with external systems (CRMs, analytics, billing), volume profile and seasonal patterns. The output is a 5-10 page migration plan that becomes the contract scope for the actual engagement.
About 20% of discovery phases conclude with "the migration is more complex than this engagement should handle, you should hire a senior consultant or run the migration in-house with our advisory support". Honest discovery is what separates migration engagements that succeed from migration engagements that become billing disputes. Operators who reject the discovery phase and demand fixed-price migration quotes upfront are flagging that they have not done a migration before; those engagements are statistically more likely to fail. We will work with operators who want fixed-price upfront, but the price will reflect the unknown-scope risk premium.