{"id":"92cbd4cf-508e-4a4d-8866-7d5267a5f263","arxiv_id":"1908.04136","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"The paper proposes an integrated analyze, right-scaling, and right-pricing process for cloud migration TCO, illustrated with a real Azure case study.","lead":"This paper presents a step-by-step process for software producers to estimate the total cost of moving an on-premise product to the cloud, then use that cost to set a subscription price. A case study of a document management application on Microsoft Azure shows how the process works in practice.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Linear CPU-to-VM scaling in §5.2 is the load-bearing assumption; without a capacity-sharing model, the case study's TCO and derived prices are not robust.","rationale":"The reader's weakest_assumption identifies the same load-bearing concern: the linear scaling of per-tenant CPU load to multi-tenant VM count, explicitly stated in §5.2 and §5.3. This is the correct focal point because compute costs are an order of magnitude larger than storage costs in the case study, so any error in VM sizing propagates directly into the TCO and the recommended price. My reading confirms that the paper gives no formula, no capacity threshold, and no empirical evidence for linearity; the monitoring shown in Fig. 2 is a twenty-minute snapshot of a single typical tenant, which cannot validate aggregate behavior. The paper's own limitations section acknowledges the narrow scope (single provider, single application type), but the linear-scaling assumption is not listed as a limitation—it is presented as the basis for the calculation. This makes the numerical illustration illustrative rather than validated. The proposed concrete test—a load test with increasing tenant count—would settle whether the concern lands. If the required VM count at 240 tenants is close to the linear prediction, the case study's numbers stand. If it is substantially lower, the TCO and price would be too high, though the qualitative conclusion that compute dominates would likely survive. Since the reader's conditional verdict already captures this uncertainty, no verdict adjustment is needed.","tokens_in":17074,"tokens_out":3710,"duration_ms":39099,"concrete_test":"Recompute Table 13's VM counts using a measured scaling curve: deploy the same DMS workload on a D2-V3 VM and incrementally load 1, 10, 40, 80, 160, and 240 synthetic tenants, recording peak and average CPU utilization. Fit a scaling model (e.g., power law or queueing model) to the observed aggregate utilization and compare the required VM counts against the linear-multiplication counts (6/18/30 web-role and 2/4/6 worker-role VMs). If the required VM count at 240 tenants is more than 20% below the linear prediction, the TCO overestimates compute cost and the right-scaling step needs a capacity-sharing model.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The case study's compute-cost estimate, which dominates the TCO (€129,701 compute vs €293 storage), rests on an unstated scaling rule: Section 5.2 reports 'simple linear multiplication of the CPU load per tenant' with no formula, no per-VM capacity threshold, and no consideration of statistical multiplexing, and Section 5.3 explicitly assumes 'no smoothing effect of multiple tenants sharing the same application compute resources.' The VM counts in Table 13 (6/18/30 web-role VMs and 2/4/6 worker-role VMs for 80/160/240 tenants) are the load-bearing numbers. If aggregate multi-tenant demand does not scale linearly—e.g., because tenants' peak CPU loads are not coincident or because a VM can host multiple tenants below its capacity ceiling—the TCO and therefore the derived pricing would be materially different. The paper presents no empirical or analytical justification for linear scaling; the single-tenant monitoring snapshot in §5.2 is insufficient to establish it. This is an internal gap between the data presented (per-tenant loads) and the model used to size infrastructure, not merely a disagreement with an external consensus.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper proposes a three-step process (analyze and model, right-scaling, right-pricing) for estimating the total cost of ownership when migrating an on-premise software product to IaaS/PaaS, and illustrates it with a case study of a document management system migrated to Microsoft Azure. The TCO is decomposed into CapEx (implementation costs) and OpEx (storage and compute charges), and the price is derived via P = TCO*(1+l). The case study covers 240 tenants migrating over three years, using historical storage data and monitored CPU loads to estimate Azure VM counts and storage costs, and concludes that compute costs dominate and migration costs should be included in pricing decisions.","tokens_in":17370,"tokens_out":5481,"duration_ms":54932,"significance":"If the process holds up, it addresses a real and under-studied link between architecture choices, cloud operating costs, and SaaS pricing. The case study is a concrete and transparent illustration: the authors state their assumptions explicitly (no caching, no query optimization, no performance tuning, no smoothing), present detailed cost tables, and make the arithmetic checkable. The main limitation is that the central right-scaling step rests on an unstated and unvalidated linear scaling rule, which propagates directly into the dominant compute-cost figure and hence into the derived prices. The paper is honest about being an 'initial process', but that framing does not remove the need for the sizing rule to be justified or for the results to be shown robust to that rule.","major_comments":[{"comment":"The number of web-role and worker-role VMs (6/18/30 and 2/4/6 for 80/160/240 tenants) is the most consequential input to the TCO, since compute costs (€129,701) dominate the total. The text says only that VM requirements were computed by 'simple linear multiplication of the CPU load per tenant' and Section 5.3 explicitly assumes 'no smoothing effect of multiple tenants sharing the same application compute resources.' No formula is given for converting per-tenant CPU load into a VM count, no per-VM capacity ceiling or SLA utilization threshold is specified, and no evidence is provided that multi-tenant aggregate load scales linearly. If tenant peaks are not coincident, or if a single VM can host several tenants below its capacity ceiling, the VM counts—and hence the TCO and the derived price from Eq. (1)—change materially. The paper should either define and justify a concrete scaling/capacity model with data, or re-frame the case study as conditional on the linear-scaling assumption and add a sensitivity analysis.","section":"Section 5.2/Table 13"},{"comment":"The workload percentages (web peak 67.1%, web average 31.5%, worker peak 24.3%, worker average 10.4%) are presented as the basis for sizing, but the measurement procedure is not reported: over what period, on how many tenants, with what workload mix, and with what variability? The text refers to a 'snapshot' of one typical tenant, which is insufficient to establish that these percentages represent the 80-, 160-, and 240-tenant cohorts that Table 13 is sized for. Without this information, the TCO calculation is not reproducible and the right-scaling step cannot be independently assessed.","section":"Section 5.2/Table 9"},{"comment":"Section 4.2 lists 'A sensitivity analysis of I/PaaS costs to potential changes in SaaS usage' as one of the steps to take, but Section 5 does not present one. Given the uncertainty in both the usage forecast (Table 8) and the VM sizing rule, a sensitivity analysis is not optional; it is required to support the claim that the process is usable for migration decisions and price setting. The case study should include at least a one-way sensitivity analysis over the CPU-load percentages and the reserved/on-demand instance split.","section":"Section 4.2 vs. Section 5"}],"minor_comments":[{"comment":"The first paragraph says the SP 'overs document management services'; this should be 'offers document management services'.","section":"Section 5.1"},{"comment":"The text states that storage 'accounts for a very tiny portion of the TCO (€293.31 – 0.001%)'; using the reported compute cost of €129,701 and storage cost of €293.31, the storage share is approximately 0.23%, so the percentage should be corrected or a different denominator stated.","section":"Section 5.3"},{"comment":"The acronym 'I/PaaS' is used throughout but is not expanded at first use; define 'IaaS/PaaS' when it first appears.","section":"Section 1"},{"comment":"The term 'DaaS storage' is introduced without expansion; spell out 'Data-as-a-Service' at first mention.","section":"Section 5.2"},{"comment":"The paper states that 'observations should also hold for applications with less data volume' in Section 5.3; this generalization is not supported by the single-case evidence and should be presented as a hypothesis, not a conclusion.","section":"Conclusions"}],"recommendation":"major_revision","confidential_remarks":"The chapter relies heavily on the authors' own prior work: the process diagram, most tables, and the case study data are adapted from reference [53], a CLOSER 2018 paper. The present chapter adds the pricing discussion and a fuller presentation of the process, but the core empirical contribution is not new. This is acceptable for a book chapter if the incremental contribution relative to [53] is stated clearly, but the editor may want to ask the authors to make that relationship more explicit. The absence of an underlying dataset or code also makes independent verification difficult."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nThis book chapter extends the authors' CLOSER paper; the core process and most tables are adapted from there. What's new is the explicit three-step framing (analyze/model, right-scaling, right-pricing) and the case study showing how compute dominates TCO and why migration costs belong in the pricing decision. The presentation is clear, the Azure cost figures are concrete, and the authors are unusually honest about their assumptions (no caching, no query optimization, no smoothing). That transparency is the paper's best feature.\n\nThe soft spot is exactly where the stress-test points. The compute costs, which are 99.8% of the OpEx, come from VM counts derived by 'simple linear multiplication of the CPU load per tenant.' No formula is given, no per-VM capacity threshold, no treatment of statistical multiplexing. The authors explicitly assume no smoothing effect from multi-tenant sharing. If real aggregate demand isn't linear—and it often isn't, because tenant peaks don't coincide and a VM can host multiple tenants below its ceiling—the TCO and the derived prices change materially. The single-tenant monitoring snapshot in §5.2 can't establish linear scaling. This is an internal gap between the data presented and the model used, not just a missing external validation.\n\nTwo more minor complaints: the leap from one document-management case to 'the majority of typical transactional business applications' is unwarranted, and the sensitivity analysis promised in §4.2 never really appears. On the citation pattern: self-citation is heavy, but legitimate since they are explicitly extending their own earlier process.\n\nWho is this for? Practitioners and researchers in cloud economics who want a concrete template for linking architecture choices to cost, and a worked example of one SME's migration. It's not a scientific breakthrough, but as a process proposal with a real case it deserves a serious referee. If I were reviewing, I'd ask them to either justify the linear scaling or present the VM-count derivation, and to soften the generalization claim. As it stands, conditional acceptance would be right.","headline":"A transparent, practitioner-oriented TCO process with a real case study, but the load-bearing VM count rests on an unstated linear-scaling assumption.","tokens_in":17865,"tokens_out":2046,"would_cite":false,"duration_ms":20973,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A three-step process turns forecast SaaS usage into an IaaS/PaaS cost estimate and a SaaS price; a document-management case study shows compute, not storage, drives the total.","keywords":["total cost of ownership","cloud migration","SaaS pricing","right-scaling","IaaS/PaaS cost estimation","software producer","multi-tenant workloads","cloud economics"],"falsifier":"Run the same document-management workload with multiple tenants sharing the same web and worker VMs in a controlled cloud testbed, and measure the actual CPU utilisation and the number of VMs needed to meet the latency target; a systematic difference from the linear per-tenant multiplication used in the case study would disprove the cost estimates. A second check is to compare the eleven-month single-tenant usage forecast against the realised usage of the 240 migrated clients over the three-year period.","tokens_in":16917,"feed_emoji":"☁️","tokens_out":6551,"duration_ms":63793,"temperature":0.7,"pith_summary":"Software producers moving an on-premise product to the cloud need to know what the service will cost to run before they can price it. This paper claims that the right way to get that number is a three-step process: analyse the existing architecture and migration context, right-scale forecast SaaS usage to concrete IaaS/PaaS configurations, and then set the SaaS price from the resulting total cost of ownership. The process is illustrated on a real document-management application migrated for 240 client installs over three years, where compute turned out to dominate operating cost while storage was negligible. The authors' central point is that architecture selection and pricing are the same problem, and that ignoring one-time migration costs leads to underpriced SaaS offerings.","feed_headline":"SaaS prices should be built from cloud usage forecasts: case study","feed_subtitle":"A three-step process maps forecast SaaS use to IaaS/PaaS costs and folds one-time migration costs into the price.","key_machinery":"The carrying object is the usage-to-cost mapping between the SaaS service provided and the I/PaaS services consumed. The process needs two maps: one from SaaS to I/PaaS metrics, linking expected and actual service-level quality to resources, and one from SaaS to I/PaaS usage patterns, linking usage variation to required resource levels. These maps feed a cost model with three resource categories (compute, storage, network) and the formula $TCO = CapEx + OpEx$, where $CapEx$ covers migration and implementation and $OpEx$ covers fixed and variable IaaS/PaaS charges; price is then set as $P = TCO \\cdot (1 + \\lambda)$, with $\\lambda$ the producer's target profit margin, which can be negative. In the case study the mapping is operationalised by monitoring a typical tenant's CPU load and storage volumes, sizing VM counts by linear multiplication of per-tenant CPU load, and assuming an 80/20 split between reserved and on-demand instances.","core_discovery":"The central claim is that right-scaling, defined as sizing a predicted workload to a machine configuration profile, should be the basis for right-pricing: a software producer's SaaS price should be built from a total cost of ownership that includes both operating expenditure (compute, storage, network costs derived from forecast usage) and capital expenditure (migration and implementation costs). The case study applies the process to a document management system being re-engineered for a public cloud, producing a three-year cost picture in which compute costs are the dominant operating component (about €129,701) while storage is tiny (about €293), and the one-time implementation and migration cost (€168,647) is large enough that omitting it would materially change the recommended price. The paper therefore concludes that migration costs must be included in TCO calculations that inform both adoption and pricing decisions.","pith_inferences":["If multi-tenant CPU demand turns out not to scale linearly, the method still works but the linear sizing rule would need replacing with a measured consolidation curve; that would make the case study a usable test rather than just an illustration.","The same mapping logic could be applied to serverless or function-as-a-service offerings, where the usage-to-cost mapping runs at the level of function executions rather than VM instances; the paper lists serverless as future work, and the framework would need a new resource model.","The case study's 'compute dominates, storage is negligible' finding is likely to hold for image- and document-heavy workloads, but data-transfer-heavy or long-term archive-heavy SaaS services could easily invert the cost structure, so the process matters more than the specific numbers."],"forward_implications":["A software producer can produce a defensible pre-migration cost estimate by combining usage forecasts, benchmarked VM performance, and provider price lists before committing to a target architecture.","Compute, not storage, is the cost component that should drive right-scaling decisions; in the case study storage accounts for a negligible share of operating cost.","One-time migration costs belong in the price; in the case study the €168,647 capital expenditure is comparable to or larger than the three-year operating costs.","The formula $P = TCO \\cdot (1 + \\lambda)$ gives an explicit lever for testing pricing strategies, including negative margins used for market entry.","Because usage forecasts carry uncertainty, the process should be paired with sensitivity or scenario analysis before a pricing model is locked in."],"supporting_citations":[{"why":"The paper's own earlier process paper; supplies the cost-estimation steps and the provider pricing tables used in the case study.","marker":"[53]"},{"why":"Supplies the comprehensive list of TCO cost components that structures the CapEx/OpEx breakdown.","marker":"[62]"},{"why":"Documents methodological flaws in existing TCO frameworks, motivating the integrated architecture-cost process.","marker":"[52]"},{"why":"Provides the 'apples-to-apples' comparison and hidden-cost warnings that justify including migration costs in TCO.","marker":"[32]"},{"why":"Supplies the migration context model (setting, drivers, ignorance, concerns) used in Step 1.","marker":"[49]"},{"why":"Provides cloud migration patterns used to inform the migration plan and architecture selection.","marker":"[34]"}],"fun_headline_variants":["Migration costs belong in your SaaS price","Right-scaling cloud workloads sets the right SaaS price","Case study: TCO for cloud migration must include one-time costs","Don't set SaaS prices without migration costs","Pricing SaaS? Start with forecast usage and migration costs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The estimate assumes that the computing power a group of tenants needs is exactly the per-tenant CPU load multiplied by the number of tenants, with no sharing or smoothing of capacity between tenants; if real multi-tenant workloads do not scale that way, the VM counts, the total cost, and the resulting prices will be wrong.","fun_headline_variants_meta":{"raw":{"variants":["Migration costs belong in your SaaS price","Right-scaling cloud workloads sets the right SaaS price","Case study: TCO for cloud migration must include one-time costs","Don't set SaaS prices without migration costs","Pricing SaaS? Start with forecast usage and migration costs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000163,"raw_usage":{"total_tokens":1175,"prompt_tokens":809,"completion_tokens":366,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":425,"completion_tokens_details":{"reasoning_tokens":291}},"tokens_in":425,"tokens_out":366,"duration_ms":4082,"temperature":1.0,"reasoning_tokens":291,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T13:49:38.280257+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same document-management workload with multiple tenants sharing the same web and worker VMs in a controlled cloud testbed, and measure the actual CPU utilisation and the number of VMs needed to meet the latency target; a systematic difference from the linear per-tenant multiplication used in the case study would disprove the cost estimates. A second check is to compare the eleven-month single-tenant usage forecast against the realised usage of the 240 migrated clients over the three-year period.","supporting_citations":[{"cited_title":"In: 8th International Conference on Cloud Computing and Services Science (CLOSER) (2018)","cited_arxiv_id":null,"evidence_quote":"The paper's own earlier process paper; supplies the cost-estimation steps and the provider pricing tables used in the case study."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the comprehensive list of TCO cost components that structures the CapEx/OpEx breakdown."},{"cited_title":"In: IEEE International Conference on Cloud Computing Technology and Science (CloudCom), pp","cited_arxiv_id":null,"evidence_quote":"Documents methodological flaws in existing TCO frameworks, motivating the integrated architecture-cost process."},{"cited_title":"https://www.isaca","cited_arxiv_id":null,"evidence_quote":"Provides the 'apples-to-apples' comparison and hidden-cost warnings that justify including migration costs in TCO."},{"cited_title":"In: Lau, K.-K., Lamersdorf, W., Pimentel, E","cited_arxiv_id":null,"evidence_quote":"Supplies the migration context model (setting, drivers, ignorance, concerns) used in Step 1."},{"cited_title":"In: International Workshop on Engineering Service Oriented Applications – WESOA 2014 (2014)","cited_arxiv_id":null,"evidence_quote":"Provides cloud migration patterns used to inform the migration plan and architecture selection."}],"review_version":1}