Ponadto trzeba wzięć pod uwagę liczbę wewnętrznych lub zewnętrznych użytkowników, którzy będą mogli korzystać z usługi i ocenić, jaka dodatkowa infrastruktura może być tu potrzebna. Ocena musi też obejmować inne niezbędne mechanizmy cloud computing (autoprovisioning, wielodzierżawność), oszacowanie kosztów i zasobów ludzkich niezbędnych do zaprojektowania interfejsu usługi, określenie zakresu prac związanych z integracją z istniejącym systemem zabezpieczeń.

Niezbędne jest też nakreślenie planów testowania i uruchamiania oraz dokonanie wyceny kosztów projektowych, uwzględniających również infrastrukturę wymaganą do ewentualnego przeskalowania projektu w przyszłości.

Jako zasadę generalną należy przyjąć, że im starsze i bardziej skomplikowane aplikacje, tym większe koszty migracji, które w skrajnych przypadkach mogą okazać się nie do przyjęcia. Konieczne jest także uwzględnienie realiów technicznych, takich jak np. spadek wydajności. Praktycznie każda aplikacja wewnętrzna doświadcza pewnego spadku wydajności, kiedy zostanie udostępniona przez internet.

Tworząc założenia biznesowe dla przeniesienia aplikacji w chmurę trzeba uwzględnić: koszt migracji, koszt ryzyka, koszty bieżącej konserwacji oraz wartość, jaką przedsięwzięcie to wnosi do biznesu. Koszty migracji to w praktyce koszty zmian w aplikacjach, wymaganych przy przeniesieniu ich w chmurę. Obejmują one nowy sprzęt i programowanie, jak również zmiany w architekturze i samym projekcie aplikacji. Uwzględnić też trzeba koszty programistyczne, zasoby do testowania, koszty wdrożenia itp.

Koszt ryzyka to cena, jaką przyjdzie zapłacić, jeżeli przeniesienie aplikacji w chmurę nie powiedzie się. Natomiast koszty bieżącej konserwacji to koszty utrzymania usługi w ruchu.

Potencjalne zyski z aplikacji przeniesionej w chmurę, takie jak poprawienie poziomu usług dla istniejących klientów i większe szanse na ich utrzymanie, określają jej wartość dla biznesu. Ostateczna wartość cloud service to jej wartość biznesowa pomniejszona o koszt ryzyka, koszt migracji i koszt utrzymania w ruchu.

Ocena istniejącej architektury aplikacji

Po wstępnej ocenie kosztów należy przyjrzeć się istniejącej architekturze aplikacji, samym aplikacjom, a w szczególności: danym, usługom, procesom, sieci, interfejsom użytkownika, interfejsom programowym (API - application programming interface), zabezpieczeniom, zarządzaniu, możliwości skalowania.

Dużo zależy od wieku aplikacji i tego, jak zostały zaprojektowane. Nowsze aplikacje zazwyczaj będą zbudowane z użyciem API zarówno w obszarze działania, jak i danych. Starsze aplikacje mogą nie mieć żadnych API i będą wymagać większych przeróbek przy przenoszeniu ich do chmury. Zawsze istnieje jakiś sposób na komunikowanie się ze starszymi aplikacjami - interfejsy transakcyjne, bezpośredni dostęp do danych czy nawet screen scraping (wydobywanie danych z wyjścia programu przeznaczonego dla ich prezentacji). Jednak często takie rozwiązania stwarzają problemy, przede wszystkim z wydajnością i skalowalnością. Należy więc rozważyć zasadność wykorzystania takich interfejsów mając na uwadze konieczność bardziej inwazyjnego przeprogramowania.

Po rozpoznaniu architektury konieczne będzie znalezienie optymalnego sposobu przekształcenia usług aplikacyjnych, w usługi w chmurach. Potrzebna tu będzie wiedza o strukturze i wewnętrznych mechanizmach bazy danych, rodzaju dostępu do bazy danych, użyciu i wykonaniu logiki biznesowej, o integracji z interfejsem użytkownika i o różnych innych rdzennych procesach biznesowych.