विभिन्न ई-कॉमर्स इंजनों के बीच माइग्रेटिंग डेटा

समस्या

आज ऑनलाइन स्टोर के लिए तीन सौ से अधिक विभिन्न इंजन हैं, अलग-अलग कार्यक्षमता, क्षमताओं, लागत, स्थापना विधि के साथ। एक नियम के रूप में, यह स्क्रिप्ट का एक सेट है जो एक होस्टिंग (व्यावहारिक रूप से एक साइट को स्थापित करने) पर तैनात किया जाता है, सबसे अधिक बार PHP + MySQL।

हाल ही में, तथाकथित होस्ट किए गए शॉपिंग कार्ट ई-कॉमर्स प्लेटफॉर्म के बाजार में एक बड़े स्थान पर हैं। इसका मतलब यह है कि एक ही Shopify की वेबसाइट पर पंजीकरण करके, कुछ ही क्लिक में आप एक ट्रायल स्टोर प्राप्त कर सकते हैं, जिसे Shopi पर होस्ट किया जाता है। परीक्षण अवधि और सीमित कार्यक्षमता, एक नियम के रूप में, कार्ड की क्षमताओं का परीक्षण करने के लिए काफी पर्याप्त हैं। इसके अलावा, इस तरह का एक समाधान, निश्चित रूप से, अपने स्वयं के होस्टिंग को किराए पर लेने, इंजन स्थापित करने और सभी आवश्यक PHP मॉड्यूल आदि से संबंधित सिरदर्द से राहत देता है, सब कुछ पहले से ही तैनात किया गया है, जैसा कि वे कहते हैं, भुगतान करें और उपयोग करें।

नतीजतन, विभिन्न प्लेटफ़ॉर्म स्टोर डेटा तक पहुंचने के विभिन्न तरीके हैं। यदि एक खुला स्रोत कार्ड ("होस्ट नहीं किया गया") सीधे डेटाबेस तक पहुँचा जा सकता है, तो सास-समाधान ऐसा अवसर नहीं देते हैं। वैकल्पिक विकल्प एपीआई अनुरोधों के माध्यम से पहुंच सकते हैं (और यह बहुत अच्छा है यदि प्लेटफ़ॉर्म आपको इस तरह से सभी आवश्यक डेटा प्राप्त करने की अनुमति देता है, क्योंकि कभी-कभी डेवलपर्स केवल इस या उस इकाई के साथ काम करने के सभी तरीकों को नहीं जोड़ते हैं) या फ़ाइलों का उपयोग करके डेटा आयात / आयात करते हैं (सीएसवी) XML, txt, dat, xls और इंजन के आधार पर अन्य प्रारूप)।

उत्तरार्द्ध विधि लगभग सभी प्लेटफार्मों द्वारा समर्थित है (हालांकि प्रत्येक की अपनी सीमाएं हैं) और एक ही कार्ड के बीच प्रवास को सरल करता है। लेकिन जब आपको ऑस्काम के आधार पर स्टोर से स्थानांतरित करने की आवश्यकता होती है, जो अस्तित्व में है और एक साल से अधिक समय से कार्य कर रहा है, तो मैगेंटो या बिगकामर्स के एक नए संस्करण में, कार्य बहुत अधिक जटिल हो जाता है।

एक डेवलपर के लिए ऐसा लक्ष्य है, इसे हल करने के दो संभावित तरीके हैं:

• स्वचालित माइग्रेशन के लिए तैयार टूल का उपयोग करें;
• यदि पिछला विकल्प सभी आवश्यकताओं को पूरा नहीं कर सकता है, तो अपना स्वयं का समाधान खोजें / विकसित करें: एक मॉड्यूल या एक अलग स्क्रिप्ट जो कम से कम पुराने प्लेटफ़ॉर्म से निर्यात की गई फ़ाइल के प्रारूप को नए एक में आयात करने के लिए बदलती है (यदि प्लेटफ़ॉर्म फ़ाइलों के साथ काम करना समर्थन करता है)।

बेशक, आप मैन्युअल रूप से व्यवस्थापक प्लेटफ़ॉर्म के माध्यम से नए प्लेटफ़ॉर्म में डेटा दर्ज कर सकते हैं, लेकिन जब उत्पादों और / या उपयोगकर्ताओं की संख्या को तीन-अंकीय संख्याओं में मापा जाता है, तो यह विकल्प एक विकल्प के रूप में बंद हो जाता है :)

इसलिए, हम पहले 2 मामलों पर विचार करते हैं।

कस्टम माइग्रेशन

डेटा ट्रांसफर का यह तरीका लंबा हो सकता है और इसकी लागत, स्वचालित माइग्रेशन की तुलना में, अधिक से अधिक भी हो सकती है।

क्यों?

यह सरल है, क्योंकि आपको एक प्रोग्रामर को नियुक्त करने की आवश्यकता है जो इस कार्य पर काम करेगा। बेशक, किसी व्यक्ति के काम के लिए, मशीन नहीं, आपको अधिक भुगतान करना होगा। और यहां तक ​​कि अगर आप खुद एक प्रथम श्रेणी के प्रोग्रामर हैं और आपकी ज़रूरत की स्क्रिप्ट लिखने में काफी सक्षम हैं, तो इसमें आपका समय लगेगा, और इसे पैसे के लिए जाना जाता है। खासकर यदि आप एक अच्छे प्रोग्रामर हैं।

विचार करने के लिए एक और कारक एक समाधान विकसित करने में लगने वाला समय है। और यदि आपकी व्यावसायिक परियोजना तत्काल पर्याप्त है, तो निश्चित रूप से आपके पास पर्याप्त समय नहीं होगा।

दूसरी ओर, इस दृष्टिकोण की विशेषता है कि बढ़ी हुई लागत और विकास का समय एक बड़े लाभ द्वारा उचित ठहराया जा सकता है - विशिष्ट लक्ष्यों और आवश्यकताओं के लिए अनुकूलन। हालांकि, सीमाएं हो सकती हैं, लेकिन उनके बारे में थोड़ी देर बाद।

स्वचालित उपकरण प्लेटफ़ॉर्म की सीमित संख्या का समर्थन करते हैं। जो, एक तरफ, निस्संदेह एक प्लस है, क्योंकि इस तरह के माइग्रेशन को वर्षों के उपयोग और हजारों माइग्रेशन द्वारा पॉलिश किया गया है। लेकिन एक ही समय में, यह भी एक माइनस है, क्योंकि यह आपको इन प्लेटफार्मों के लिए डेटा का केवल एक सामान्य सेट सेट करने और उन्हें इस तरह से व्याख्या करने की अनुमति देता है जैसे कि यह उपकरण में है। उदाहरण के लिए, विभिन्न कार्डों में कर के सार को पूरी तरह से अलग-अलग तरीकों से कॉन्फ़िगर और उपयोग किया जा सकता है, जिसमें पूरी तरह से अलग तत्व और डेटा शामिल हैं। इसलिए, माइग्रेशन हो जाएगा क्योंकि यह टूल में है। एक कस्टम टूल का उपयोग करके, ऐसी चीजों को कम से कम किया जा सकता है, क्योंकि यह एक विशिष्ट मामले के लिए विकसित किया जाएगा।

कस्टम समाधान यथासंभव प्रभावी होने के लिए, आपको उन प्लेटफार्मों पर अधिक विस्तार से अध्ययन करना चाहिए जिनके साथ आपको काम करने की आवश्यकता है। संस्थाओं का अन्वेषण करें और उन्हें सही ढंग से काम करने के लिए उनके बीच संबंधों का निर्धारण करें। यह याद रखना चाहिए कि यदि प्लेटफ़ॉर्म अलग हैं, तो उनमें से एक ऐसी इकाई का समर्थन कर सकता है जो दूसरे के पास नहीं है। उदाहरण के लिए, मैगेंटो में उत्पाद वेरिएंट की अवधारणा है, लेकिन ओपनकार्ट में यह नहीं है। महत्वपूर्ण रूप से कम अक्सर, लेकिन अभी भी ऐसे मामले हैं जब इकाई को दोनों प्लेटफार्मों द्वारा माना जाता है, लेकिन यह प्रत्येक पर एक अलग तरीके से बनाया गया है और एक ही समय में इसका पूरी तरह से अलग उद्देश्य हो सकता है।

डेटा तक पहुंचने की विधि पर विशेष ध्यान दिया जाना चाहिए, क्योंकि यह विशेष भाग भविष्य के समाधान का "अड़चन" बन सकता है। यदि शॉपिंग कार्ड होस्ट नहीं किया गया है, अर्थात्, डेटाबेस के साथ स्क्रिप्ट का एक सेट स्थापित है, तो आपके पास इस डेटाबेस तक भौतिक पहुंच है, और इसलिए आप उसी तरह से सभी आवश्यक डेटा प्राप्त कर सकते हैं जैसे आप इसे इस डेटाबेस में जोड़ सकते हैं। मुख्य बात यह समझना है कि कहां और क्या जानकारी स्थित है, इसका क्या मतलब है और यह कैसे बनता है। इसके अलावा, ऐसे मानचित्रों में आपके पास फ़ाइलों तक पहुंच होती है: सामान की छवियां, माल के लिए डाउनलोड करने योग्य डेटा, आदि।

इस स्थिति में, डेटा माइग्रेशन योजना इस तरह दिखाई देगी:



विभिन्न सर्वरों पर 2 स्टोर हैं। माइग्रेशन स्क्रिप्ट को किसी एक सर्वर पर स्थापित किया जाता है और इस सर्वर के डेटाबेस से एक सीधा कनेक्ट किया जाता है। किसी अन्य स्टोर से कनेक्ट करने के लिए, आप डायरेक्ट कनेक्ट का उपयोग कर सकते हैं, लेकिन इसके लिए आपको बाहर से पहुंच खोलने की आवश्यकता है।

यदि सर्वर उसी सर्वर पर है, तो अतिरिक्त पहुंच की आवश्यकता नहीं है। आप उसी का उपयोग कर सकते हैं जो स्टोर खुद को डेटाबेस से कनेक्ट करने के लिए उपयोग करता है। आमतौर पर वे स्टोर की कॉन्फ़िगरेशन फ़ाइल में पाए जा सकते हैं (उदाहरण के लिए, config.php या स्टोर की रूट डायरेक्टरी में config.php)।



PHP में डेटाबेस से जुड़ने के लिए उदाहरण वर्ग:

class Db { private $_link = null; private $_triesCount = 10; public function connect($config) { while (!$this->_link) { if (!$this->_triesCount--) { break; } $this->_link = mysql_connect($config['dbHost'], $config['dbUser'], $config['dbPass']); if (!$this->_link) { sleep(5); } } if (!$this->_link) { die(mysql_error($this->_link)); } mysql_select_db($config['dbName'], $this->_link); } public function query($sql) { $query = mysql_query($sql, $this->_link); if (!$query) { die(mysql_error($this->_link)); } return $query; } public function cntRows($query) { return mysql_num_rows($query); } } 

माइग्रेशन प्रक्रिया में निम्नलिखित चरण होते हैं:

1. स्रोत स्टोर से डेटा खींचना: एक डेटाबेस से; एपीआई के माध्यम से; फाइलों से।
2. लक्ष्य स्टोर प्रारूप में डेटा लाना: लक्ष्य स्टोर की तालिका या फ़ाइल संरचना में।
3. लक्ष्य पक्ष पर डेटा डालें: डेटाबेस में, एपीआई के माध्यम से, फाइलों में।

होस्ट किए गए शॉपिंग कार्ड के साथ सब कुछ थोड़ा अलग है। डेटाबेस में कोई सीधी पहुंच नहीं है, क्योंकि स्टोर डेवलपर के सर्वर पर स्थापित है, और आपको केवल इसे व्यवस्थापक पैनल से प्रबंधित करने का अवसर दिया जाता है। डेटा प्राप्त करने के लिए, होस्ट किए गए शॉपिंग कार्ड के कुछ डेवलपर्स (दुर्भाग्य से, सभी नहीं) एक विशिष्ट एपीआई प्रदान करते हैं, जिसमें इस डेटा के साथ काम करने के तरीकों का एक सेट शामिल है।



सच है, कार्ड पर निर्भर करता है, यह सेट बल्कि मतलब हो सकता है और कार्य की आवश्यकताओं को पूरा नहीं कर सकता है। ये ऐसी सीमाएँ हैं जिनका पहले उल्लेख किया गया था। उदाहरण के लिए, Shopify, काफी अच्छी तरह से कार्यान्वित और प्रलेखित तरीकों के बावजूद, ग्राहक के आदेश बनाने की अनुमति नहीं देता है। आप केवल मौजूदा लोगों के बारे में जानकारी देख सकते हैं या उनमें से किसी एक की स्थिति बदल सकते हैं। और Miva Merchant में API के माध्यम से काम करने की क्षमता नहीं है। एपीआई की एक और विशेषता समय की प्रति अवधि अनुरोधों की संख्या पर सीमा है। यदि स्क्रिप्ट या प्रोग्राम इस सीमा से अधिक है, तो बाद के अनुरोधों को कई मिनटों तक निष्पादित नहीं किया जा सकता है।

लगभग हर शॉपिंग कार्ड में फ़ाइलों के रूप में डेटा का निर्यात / आयात होता है। यदि ऐसी फ़ाइलों की जानकारी सफल प्रवास के लिए पर्याप्त है, तो डेटाबेस तक पहुंच की आवश्यकता नहीं है। अक्सर, नक्शे द्वारा निर्यात की गई फ़ाइलों की संरचना डेटाबेस की संरचना से अधिक सहज होती है, और एपीआई अनुरोधों की प्रतिक्रियाओं की सामग्री से अधिक पूर्ण होती है। डेटाबेस से सीधे संबंध की कमी आपको उपकरण को अधिक लचीला बनाने की अनुमति देती है: यह एक विशिष्ट फ़ाइल प्रारूप के लिए तेज किया जाएगा और डेटाबेस तक पहुंच अधिकार या एपीआई अनुरोधों की संख्या पर प्रतिबंध जैसी चीजों पर निर्भर नहीं करेगा। खरीदारी कार्ड के बीच भंडारण मीडिया के रूप में फ़ाइलों का उपयोग करना, आप आमतौर पर अपनी खुद की कोई स्क्रिप्ट या प्रोग्राम नहीं बना सकते हैं। यह इन फ़ाइलों को संपादित करने के लिए, उन्हें वांछित प्रारूप में लाने के लिए पर्याप्त है।

कई फ़ाइल प्रवास योजनाएँ:

1. एक फ़ाइल स्वरूप को दूसरे में बदलें:



2. फ़ाइल से डेटाबेस में प्रवासन:



3. डेटाबेस से फाइल में माइग्रेशन:



इस तरह के पलायन के चरण लगभग पिछले उदाहरणों के समान होंगे, लेकिन अतिरिक्त चरण हो सकते हैं:

1. स्रोत से फ़ाइलों तक डेटा निर्यात करें।
2. फ़ाइलों से डेटा खींचना।
3. लक्ष्य प्रारूप में डेटा लाना: तालिकाओं या स्टोर की लक्ष्य फ़ाइल की संरचना में।
4. लक्ष्य स्टोर के लिए फ़ाइलों का निर्माण।
5. स्टॉर को लक्षित करने के लिए उत्पन्न फ़ाइलें आयात करें।

वैसे, यदि विकल्प जहां आप डेटाबेस सर्वर तक पहुंच खोलना चाहते हैं, अस्वीकार्य है, तो आप फ़ाइलों के रूप में डेटाबेस से डेटा प्राप्त कर सकते हैं। phpMyAdmin आपको CSV, XML और अन्य फ़ाइलों के रूप में तालिका सामग्री निर्यात करने की अनुमति देता है।

कस्टम टूल के लिए आवश्यक संसाधनों के लिए, यह उस डेटा की मात्रा पर निर्भर करेगा जिसे स्थानांतरित करने की आवश्यकता है, और स्क्रिप्ट का कार्यान्वयन। अधिक विश्वसनीयता और कम संसाधन खपत के लिए, बैचों में डेटा स्थानांतरित करना बेहतर है, उदाहरण के लिए, 100 संस्थाओं की सरणियाँ।

सामान्य तौर पर, यदि आप एक PHP स्क्रिप्ट के विकल्प पर विचार करते हैं जो किसी एक सर्वर पर चलेगा, तो यह निम्नलिखित बातों पर विचार करने के लायक है:

• स्क्रिप्ट सर्वर पर एक अतिरिक्त लोड बनाता है, जो एक ही सर्वर पर स्थित साइटों या साइटों के संचालन को प्रभावित कर सकता है;
• स्क्रिप्ट को एक निश्चित मात्रा में RAM की आवश्यकता होती है, जो सीधे स्क्रिप्ट के कार्यान्वयन पर निर्भर करता है, विशेष रूप से, डेटा पैकेट के आकार पर जो एक पुनरावृत्ति में स्थानांतरित किया जाएगा;
• डेटाबेस या फ़ाइलों के साथ काम करते समय स्क्रिप्ट डिस्क सिस्टम पर अतिरिक्त लोड बनाता है;
• डेटा ट्रांसफर प्रक्रिया की अवधि इस डेटा की मात्रा पर निर्भर करेगी और कई मिनटों से लेकर कई घंटों तक रह सकती है, कभी-कभी दिन भी।

प्रोग्रामिंग भाषा के लिए जिसका उपयोग कस्टम समाधान बनाने के लिए किया जाएगा, कोई सख्त प्रतिबंध नहीं हैं। मुख्य बात यह है कि यह आपको आवश्यक कार्यक्षमता को लागू करने की अनुमति देता है, जैसे कि डेटाबेस से कनेक्ट करना (जरूरी नहीं कि MySQL), HTTP अनुरोधों का निष्पादन, फाइलों और छवियों के साथ काम करना। चूंकि प्लेटफार्मों का एक महत्वपूर्ण हिस्सा PHP में लिखा गया है, यह ठीक है कि यह सबसे अधिक बार उपयोग किया जाता है। यद्यपि वही जावा कार्य को हल करने के लिए भी उपयुक्त है।

वैसे, ऐसी कंपनियां हैं जो इस तरह के कस्टम टूल या स्क्रिप्ट बनाती हैं। विशेष रूप से, TransPacific Software Pvt। लिमिटेड Magento, X-Cart से OpenCart, Zen Cart to OpenCart या Magento, Loaded Commerce (CRE Loaded) और Magento के माइग्रेशनों के लिए 25 व्यावसायिक दिनों के लिए एक समाधान तैयार करने की पेशकश करता है।

स्वचालित माइग्रेशन

शॉपिंग कार्ड के बीच डेटा स्थानांतरित करने के लिए तैयार समाधानों में, 2 समूह हैं: कार्ड के लिए सेवाएं और एप्लिकेशन। उत्तरार्द्ध सभी कार्डों के लिए नहीं बनाए गए हैं और अधिक संकीर्ण रूप से लक्षित हैं। एक नियम के रूप में, वे केवल उस कार्ड का समर्थन करते हैं जिसके लिए उनका इरादा है। ऐसे एप्लिकेशन अपेक्षाकृत सस्ते होते हैं (यदि मुक्त नहीं हैं), खरीदारी कार्ड में से एक पर स्थापित, होस्टिंग संसाधनों का उपयोग करें, जिस पर कार्ड काम करता है।

डेटा ट्रांसफर के ऐसे साधनों को हाथ के औजारों के लिए जिम्मेदार ठहराया जा सकता है, जो उनके सार को देखते हुए उचित होगा। लेकिन यह भी विचार करते हुए कि ये अभी भी तैयार समाधान हैं, फिर, मेरी राय में, उनके पास इस श्रेणी में एक जगह है।

बदले में, स्वचालित सेवाएँ, खरीदारी कार्डों की अधिक विविधता को कवर करती हैं। समर्थित विकल्पों की सूची में विभिन्न कार्डों के लिए संयुक्त संस्थाओं की सबसे बड़ी संख्या शामिल है। यद्यपि यदि इकाई एक विशेष कार्ड के लिए अद्वितीय है, तो यह संभव है कि जब एक ही प्लेटफार्मों के बीच डेटा स्थानांतरित किया जाए, तो यह भी माइग्रेट करेगा।

बेशक, कार्ड के कस्टम मॉड्यूल द्वारा उत्पन्न डेटा को स्थानांतरित करना संभव नहीं होगा (उदाहरण के लिए, विशिष्ट रिपोर्ट)। कम से कम सेवा की मानक कार्यक्षमता में यह शामिल नहीं है। यदि आप अभी भी सेवा और आपके द्वारा आवश्यक कस्टम डेटा का उपयोग करने का निर्णय लेते हैं, तो आप हमेशा सहायता टीम से पूछ सकते हैं कि क्या अतिरिक्त काम करना संभव है। बेशक यह कीमत के लिए + होगा। स्वचालित माइग्रेशन की कीमत की बात करें: यह आमतौर पर कस्टम माइग्रेशन के मामले से कम है, क्योंकि इसके लिए प्रक्रिया में न्यूनतम मानवीय हस्तक्षेप की आवश्यकता होती है।

कुछ सेवाएं प्रवास के लिए अतिरिक्त विकल्प प्रदान करती हैं, उदाहरण के लिए, एसईओ डेटा माइग्रेशन, उत्पाद आईडी सहेजना, आदेश, आदि। इन विकल्पों की लागत को संपूर्ण प्रवासन की लागत में जोड़ा जाता है।

एक उदाहरण के रूप में, Cart2Cart सेवा पर विचार करें, जो लगभग 50 शॉपिंग कार्ड का समर्थन करती है। यह आपको माल और उनकी श्रेणियों, निर्माताओं, ग्राहक सूचियों और उनके आदेश, करों जैसे डेटा को स्थानांतरित करने की अनुमति देता है, और प्रवास की प्रत्येक विशिष्ट दिशा के लिए कई अतिरिक्त विकल्प भी हैं।

प्रवासन योजना इस प्रकार है:



साइट के डेटाबेस से कनेक्ट करने के लिए, सेवा एक विशेष कनेक्शन ब्रिज का उपयोग करती है, जो स्टोर के रूट डायरेक्टरी में पूर्वस्थापित है।

सभी माइग्रेशन अमेज़ॅन के इलास्टिक क्लाउड (EC2) सर्वर पर किए जाते हैं, जो प्रक्रिया की उच्च गति सुनिश्चित करता है और आपको बड़ी मात्रा में डेटा का सामना करने की अनुमति देता है। इस प्रकार, सभी प्रक्रियाएं समर्पित सर्वर पर होती हैं।

कुछ शॉपिंग कार्ड के लिए, फ़ाइलों से माइग्रेशन समर्थित है:

संस्थाओं के बीच संबंध

प्रत्येक शॉपिंग कार्ड में 3 मुख्य संस्थाओं को प्रतिष्ठित किया जा सकता है: सामान (उत्पाद), ग्राहक (ग्राहक), ऑर्डर (ऑर्डर) । अन्य सभी किसी न किसी तरह मुख्य लोगों के साथ जुड़े हुए हैं। संस्थाओं को पलायन करते समय, इस डेटा को लक्ष्य स्टोर में सही ढंग से पुनर्स्थापित करने के लिए उनके बीच संबंधों पर विचार करना महत्वपूर्ण है।

निम्नलिखित चित्र दूसरों के साथ मुख्य संस्थाओं के संबंधों को चित्रित करते हैं। खरीदारी कार्ड के आधार पर, उनकी सूची भिन्न हो सकती है।
उत्पाद के सार में ऐसी इकाइयाँ शामिल हो सकती हैं या उनसे संबंधित हो सकती हैं:

• श्रेणी (श्रेणियों);
• छवियाँ (चित्र);
• समीक्षाएँ (समीक्षाएं);
• विकल्प , जो बदले में, विकल्प (विकल्प आइटम) के मूल्यों को शामिल करते हैं ।

उपयोगकर्ता इकाई पते से जुड़ी होती है और इसमें कई पते हो सकते हैं।



आदेश निकाय निम्नलिखित संस्थाओं से संबद्ध है:

• उपयोगकर्ता (ग्राहक);
• बिलिंग पता
• शिपिंग पता
• उत्पादों (उत्पाद);
• कुल (कुल);
• आदेशों का इतिहास (इतिहास)।

वैसे, आदेश में , एक नियम के रूप में, उपयोगकर्ताओं और उत्पादों के बारे में जानकारी की नकल की जाती है। अर्थात्, ऑर्डर देने वाले ग्राहक की आईडी और ऑर्डर किए गए उत्पादों की आईडी को बचाने के अलावा, इन संस्थाओं के बारे में मूल जानकारी को अलग-अलग तालिकाओं में डेटाबेस में डुप्लिकेट किया जाता है। यह आपको पूर्ण आदेश की जानकारी को बचाने की अनुमति देता है, भले ही उपयोगकर्ता खाते या कैटलॉग से उत्पाद पूरी तरह से हटा दिए गए हों।

परिणाम

ई-कॉमर्स प्लेटफॉर्म के बीच डेटा माइग्रेशन की प्रक्रिया जटिल या सरल, लंबी या तेज हो सकती है। सब कुछ चुने हुए रास्ते, उपकरण और संसाधनों पर निर्भर करेगा। उद्योग के तेजी से विकास को देखते हुए (विश्लेषकों के पूर्वानुमान के अनुसार, 2017 से पहले ऑफ़लाइन स्टोरों का एक तिहाई बंद हो जाएगा), स्वचालित उपकरण सक्रिय रूप से बेहतर हो रहे हैं, जिससे सेवाओं की बढ़ती संख्या प्रदान की जा रही है, इसलिए डेटा स्थानांतरित करने के लिए कस्टम स्क्रिप्ट लिखना पृष्ठभूमि पर वापस आ गया है।