העברת Bitrix24 On-Premise לענן: מדריך להעברת פורטל ו-CRM

אתה רוצה להתרחק מניהול שרת משלך, לצמצם את תשתית ה-IT ולהשתמש ביכולות ענן שאינן זמינות בגרסת ה-On-Premise. המעבר מ-On-Premise לענן כולל אילוץ מהותי: Bitrix24 אינה מספקת כלי ייבוא רשמי מהגרסה ה-boxed. העברת נתונים אפשרית רק דרך REST API — בכיוון ההפוך בהשוואה להגירה מהענן ל-box. במהלך 5 שנים השלמנו יותר מ-30 פרויקטים כאלה ואנחנו מכירים את כל המלכודות.

Bitrix24 בענן מציעה תכונות מובנות שאינן זמינות בגרסת ה-On-Premise: טלפוניה WebRTC, אפליקציה ניידת מלאה, עדכונים אוטומטיים. זה מפחית את העומס מצוות ה-IT ומקטין את עלויות חומרת השרת ב-40-60%.

לדוגמה, עבור חברה עם 50 עובדים, החיסכון בציוד שרתים ובניהול יכול להגיע ל-עלות מחושבת לאחר ביקורת בשנה. שותפי Bitrix24 המוסמכים שלנו מבטיחים הגירה חלקה ללא זמן השבתה.

נתונים זמינים להעברה

לא כל מה שקיים בגרסה המקומית זמין בענן. הבדלים עיקריים שיש לבדוק לפני קבלת החלטה:

מדוע מודולים מותאמים אישית הם הבעיה העיקרית

אם ב-on-premise שלך יש מודולים או קומפוננטות PHP מותאמים אישית, יש לכתוב אותם מחדש כאפליקציות REST בענן. זהו האתגר העיקרי: עבודת שינוי כזו עשויה לעלות על עלות ההעברה עצמה. בשלב הביקורת, אנו מעריכים כל מודול ומספקים מסקנה.

תהליך העברת נתוני CRM

הנתונים מיוצאים מה-On-Premise דרך REST API (הפועל באופן זהה בשתי הגרסאות) ונכנסים לענן דרך אותו REST API. הרצף:

1. יצירת אפליקציית OAuth בפורטל הענן לצורך אימות בקשות.
2. העברת משתמשים — הזמנה ידנית דרך הממשק או שימוש ב-user.add (רק ב-On-Premise; ה-API בענן מגביל הוספת משתמשים).
3. יצירה מחדש של ספריות: סטטוסי עסקאות (crm.status.add), משפכים (crm.dealcategory.add), שדות משתמש (crm.userfield.add).
4. העברת נתוני CRM: חברות → אנשי קשר → לידים → עסקאות תוך שמירה על מיפוי מזהים.
5. העברת קבצי Disk דרך disk.folder.uploadfile.

סקריפט ההעברה פועל עם שני לקוחות API בו-זמנית: אחד מחובר ל-On-Premise (המקור), והשני לענן (היעד). התיעוד הרשמי של Bitrix24 Bitrix24 REST API documentation מגביל את תדירות הבקשות ל-API בענן בצורה מחמירה יותר מאשר ל-API של ה-On-Premise. בתעריף 'Team' — 2 בקשות בשנייה, ב-'Company' — עד 200. עבור נפחים גדולים, אנו מיישמים הגבלת קצב:

class RateLimiter {
    private float $lastRequest = 0;
    private float $minInterval; // seconds between requests

    public function wait(): void {
        $elapsed = microtime(true) - $this->lastRequest;
        if ($elapsed < $this->minInterval) {
            usleep((int)(($this->minInterval - $elapsed) * 1_000_000));
        }
        $this->lastRequest = microtime(true);
    }
}

מהן מגבלות API וכיצד לעקוף אותן?

מגבלות API הן גורם מכריע בתכנון. על פי תיעוד Bitrix24 REST API, המגבלות נמוכות יותר בתעריפי הענן. ה-RateLimiter לעיל הוא פתרון סטנדרטי. בפועל, אנו משתמשים במרווח זמן הניתן להגדרה ובתור משימות כדי להישאר בגבולות המגבלות. לדוגמה, תעריף 'Company' מהיר עד פי 100 מתעריף 'Team' להעברת נתונים.

Bitrix24 בענן מפחית את העלות הכוללת של הבעלות (TCO) פי 2–3 בהשוואה לגרסה המקומית על ידי ביטול חומרת השרת והניהול שלה. המשמעות היא חיסכון של עלות מחושבת לאחר ביקורת בשנה בהתאם לגודל החברה.

מה כלול בעבודה?

• ביקורת של התצורה הנוכחית: מיפוי מודולים, שדות משתמש, תהליכים עסקיים.
• הסכמה על תוכנית ההעברה: אילו נתונים להעביר, מה לשכתב.
• פיתוח סקריפטים להעברה: עם הגבלת קצב ומיפוי מזהים.
• הרצת בדיקה: על עותק של נתונים, בדיקת שלמות.
• פעולה במקביל: 2–4 שבועות של שימוש משותף ב-on-premise ובענן.
• הכשרת עובדים: עבודה עם הממשק החדש ויישומי REST.
• תמיכה לאחר ההעברה: שבועיים לאחר המעבר.

רשימת בדיקה לפני ההעברה:

• לבדוק אילו מודולי PHP בשימוש — הם לא יועברו.
• לקבוע את תעריף הענן: הוא משפיע על מגבלות API.
• למנות אחראי על מיפוי מזהי משתמשים.
• ליצור יישום OAuth בפורטל הענן.
• להכין את הסביבה לפעולה במקביל.

תקופת פעילות מקבילה

תקופת הפעילות המקבילה המומלצת היא 2–4 שבועות. במהלך תקופה זו, נתונים חדשים מוזנים לענן, בעוד שהמערכת המקומית הישנה נשארת לקריאה בלבד לצורך אימות. לאחר התקופה, יש להשבית את המערכת המקומית ולפנות את השרת. הדבר מונע השבתה של הפורטל ומאפשר אימות שלמות הנתונים.

לוחות זמנים אופייניים

עלות ההעברה משתנה בהתאם לנפח הנתונים ולמורכבות ההתאמה האישית. בקשו ביקורת של הפורטל שלכם — נקבע את התקציב המדויק ואת לוח הזמנים להעברה. צרו קשר לייעוץ. עם למעלה מ-5 שנות ניסיון ומומחים מוסמכים, אנו מבטיחים מעבר חלק.